JP2020504927A

JP2020504927A - イベントの削除を可能にする分散データベースのための方法および装置

Info

Publication number: JP2020504927A
Application number: JP2019525948A
Authority: JP
Inventors: シー．，３世ベアード，リーモン
Original assignee: スワールズ，インコーポレイテッド
Priority date: 2016-12-19
Filing date: 2017-12-19
Publication date: 2020-02-13
Anticipated expiration: 2037-12-19
Also published as: RU2019118333A3; JP7211943B2; KR102454779B1; US11222006B2; KR20210122902A; AU2017382161B2; WO2018118930A1; CN110140116A; RU2754189C2; RU2021123584A; AU2017382161A1; US20220129438A1; CN116820695A; CA3044071A1; CN110140116B; US20180173747A1; RU2019118333A; US11657036B2; EP3555757A4; EP3555757A1

Abstract

【課題】リーダーまたは信頼される第三者がデータベース・システムを運営することを要求しない、分散データベース・システムのための方法および装置の提供。【解決手段】装置は、計算デバイスの第１のグループ内に含まれるように構成された計算デバイスにある分散データベースのインスタンスに関連するメモリを含む。この装置は、イベントの集合からの各イベントの順序を、イベント同意プロトコルの異なる構成に基づいて判定するように構成される。異なる構成は、分散データベースを実施する計算デバイスの異なる構成に論理的に関係付けられる。この装置は、イベントの集合からの各イベントの判定された順序に基づいて、分散データベースのインスタンスの現在の状態を判定し、現在の状態に関連するハッシュ値に基づいて、分散データベースのインスタンスに関連する署名付き状態を生成するように構成される。この装置は、署名付き状態を示すトランザクションを含むイベントを分散データベースのインスタンスにポストするために信号を送る。【選択図】図１３

Description

関連特許出願の相互参照
［１００１］本願は、参照によってその全体が本明細書に組み込まれている、２０１６年１２月１９日に出願した米国特許仮出願第６２／４３６０６６号、名称「ＭＥＴＨＯＤＳＡＮＤＡＰＰＡＲＡＴＵＳＦＯＲＡＤＩＳＴＲＩＢＵＴＥＤＤＡＴＡＢＡＳＥＴＨＡＴＥＮＡＢＬＥＳＤＥＬＥＴＩＯＮＯＦＥＶＥＮＴＳ」の優先権を主張するものである。

［１００２］本明細書で説明される実施形態は、全般的にはデータベース・システムに関し、より具体的には、ネットワーク内の複数のデバイスにまたがってデータベース・システムを実施する方法および装置に関する。

［１００３］一部の既知の分散データベース・システムは、分散データベース・システム内の値に関する同意（たとえば、トランザクションが発生する順序に関する）を達成することを試みる。たとえば、オンライン・マルチプレイヤ・ゲームは、ユーザがゲームをプレイするためにアクセスできる多数のコンピュータ・サーバを有する場合がある。２人のユーザが、ゲーム内で特定のアイテムを同時に拾い上げることを試みる場合には、分散データベース・システム内のサーバが、２人のユーザのどちらが最初にそのアイテムを拾い上げたのかに関する合意に最終的に達することが重要である。

［１００４］そのような分散同意は、Ｐａｘｏｓアルゴリズムまたはその変形形態などの方法および／またはプロセスによって処理され得る。そのような方法および／またはプロセスの下では、データベース・システムの１つのサーバが、「リーダー」としてセット・アップされ、このリーダーが、イベントの順序を決定する。イベント（たとえば、マルチプレイヤ・ゲーム内の）は、リーダーに転送され、リーダーは、イベントの順序付けを選択し、リーダーは、その順序付けをデータベース・システムの他のサーバにブロードキャストする。

［１００５］しかし、そのような既知の手法は、データベース・システムのユーザ（たとえば、ゲーム・プレイヤ）によって信頼される当事者によって運営されるサーバ（たとえば、中央管理サーバ）を使用する。したがって、リーダーまたは信頼される第三者がデータベース・システムを運営することを要求しない、分散データベース・システムのための方法および装置の必要が存在する。

［１００６］他の分散データベースは、リーダーを有しないように設計されるが、非効率的である。たとえば、１つのそのような分散データベースは、同意を達成することのできる「ブロックチェーン」データ構造に基づく。しかし、そのようなシステムは、参加者全員に関して、合計で少数のトランザクション毎秒（たとえば、７トランザクション毎秒）に制限される可能性があり、これは、大規模なゲームまたはデータベースの多数の伝統的なアプリケーションにとって不十分である。さらに、経時的なデータベースのスケールの増大は、計算リソースの使用を増加させる可能性があり、たとえば、メモリ・リソースは、冗長なデータまたは不必要なデータを記憶するときに、管理しにくく、かつ／または十分に活用されなくなる可能性がある。したがって、リーダーなしで同意を達成し、計算リソースの管理において効率的な分散データベース・システムの必要が存在する。

［１００７］いくつかの実施形態では、装置は、計算デバイス（ｃｏｍｐｕｔｅｄｅｖｉｃｅ）の第１の群内に含まれるように構成された計算デバイスにある分散データベースのインスタンスに関連するメモリを含む。この装置は、イベントの集合からの各イベントの順序を、イベント同意プロトコルの異なる構成に基づいて判定するように構成される。異なる構成は、分散データベースを実施する計算デバイスの異なる構成に論理的に関係付けられる。この装置は、イベントの集合からの各イベントの判定された順序に基づいて、分散データベースのインスタンスの現在の状態を判定し、現在の状態に関連するハッシュ値に基づいて、分散データベースのインスタンスに関連する署名付き状態を生成するように構成される。この装置は、署名付き状態を示すトランザクションを含むイベントを分散データベースのインスタンスにポストするために信号を送る。

［１００８］一実施形態による、分散データベース・システムを示す高水準ブロック図である。［１００９］一実施形態による、分散データベース・システムの計算デバイスを示すブロック図である。［１０１０］一実施形態による、ハッシュグラフの例を示す図である。［１０１０］一実施形態による、ハッシュグラフの例を示す図である。［１０１０］一実施形態による、ハッシュグラフの例を示す図である。［１０１０］一実施形態による、ハッシュグラフの例を示す図である。［１０１１］一実施形態による、第１の計算デバイスと第２の計算デバイスとの間の通信フローを示すフロー図である。［１０１２］一実施形態による、ハッシュグラフの例を示す図である。［１０１３］一実施形態による、ハッシュグラフの例を示す図である。［１０１４］一実施形態による、ハッシュグラフと共に使用される例の同意方法を示す図である。［１０１４］一実施形態による、ハッシュグラフと共に使用される例の同意方法を示す図である。［１０１５］一実施形態による、ハッシュグラフと共に使用される例の同意方法を示す図である。［１０１５］一実施形態による、ハッシュグラフと共に使用される例の同意方法を示す図である。［１０１６］別の実施形態による、ハッシュグラフと共に使用される例の同意方法を示す図である。［１０１６］別の実施形態による、ハッシュグラフと共に使用される例の同意方法を示す図である。［１０１７］一実施形態による、分散データベースの初期状態の表現を示す図である。［１０１８］一実施形態による、分散データベースのメンバの更新、追加、除去に関連する動作の例を示す流れ図である。［１０１９］一実施形態による、受信されたラウンドに基づくイベントの受諾および拒絶を示す流れ図である。［１０２０］一実施形態による、分散データベースの２つのメンバの間での同期化プロセスを示す流れ図である。

［１０２１］いくつかの実施形態では、装置は、分散データベースを実施する計算デバイスの集合内に含まれるように構成された計算デバイスにある分散データベースのインスタンスを含む。この装置は、対の集合の関数として生成される一意識別子の指定によって保護される分散データベースの初期状態を定義するように構成されたプロセッサをも含み、各対は、分散データベースのインスタンスに関連する公開鍵およびランダム化された値を含む。分散データベースは、分散データベースを実施する計算デバイスの集合によって署名された収束状態に基づいて、分散データベースの現在の状態および将来の状態に関係しないイベントが、計算デバイスの集合の間で交換されなくなるように、分散データベースのインスタンスの間でイベントを同期化するように構成される。プロセッサは、分散データベースの署名付きの状態を定義することによって、分散データベースのインスタンスから不必要なイベントを除去するようにも構成される。これは、分散データベースを実施する計算デバイスの集合の間で冗長なイベントまたは関連しないイベントを同期化することによって引き起こされるオーバーヘッドを減らす。これは、計算デバイスのそのような集合のローカル・メモリの不十分な活用をも減らす。

［１０２２］いくつかの実施形態では、装置は、計算デバイスの群に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの群内に含まれるように構成された計算デバイスにある分散データベースのインスタンスに関連するメモリを含む。分散データベースに関連するイベント同意プロトコルの第１の構成に関連する計算デバイスの群。この装置は、メモリに動作可能に結合されたプロセッサを含む。プロセッサは、計算デバイスの群からの計算デバイスの集合から、イベントの集合を受信するように構成される。イベントの集合からの各イベントは、（１）トランザクションの集合と（２）受信されたラウンド番号とに関連する。プロセッサは、イベントの集合からの各イベントの順序を（１）そのイベントに関連する受信されたラウンド番号が分散データベースのインスタンスによって識別された受信されたラウンド番号しきい値を超えないときには、イベント同意プロトコルの第１の構成に、（２）そのイベントに関連する受信されたラウンド番号が受信されたラウンド番号しきい値を超えるときには、イベント同意プロトコルの第２の構成に基づいて判定するように構成される。このプロセッサは、イベントの集合からの各イベントの判定された順序に基づいて、分散データベースのインスタンスの現在の状態を判定するように構成される。このプロセッサは、現在の状態に関連するハッシュ値に基づいて、分散データベースのインスタンスに関連する署名付き状態を生成するように構成される。ハッシュ値は、第１の計算デバイスに関連する秘密鍵を用いてデジタル署名される。このプロセッサは、署名付き状態を示すトランザクションを含むイベントを分散データベースのインスタンスにポストするために信号を送るようにさらに構成される。

［１０２３］いくつかの実施形態では、装置は、計算デバイスの群に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの群内に含まれるように構成された第１の計算デバイスにある分散データベースのインスタンスに関連するメモリを含む。この装置は、メモリに動作可能に結合されたプロセッサを含む。プロセッサは、計算デバイスの群からの第２の計算デバイスからイベントを受信するように構成される。イベントは、親イベントの集合に関連するバイトのシーケンスである。親イベントの集合からの各親イベントは、（１）ハッシュ値と（２）作成済みラウンド値とに関連する。このプロセッサは、第１の判断基準または第２の判断基準のうちの少なくとも１つが満足されるときに、イベントの順序の判定から受信されたイベントを除外するように構成される。第１の判断基準は、（１）親イベントの集合からの少なくとも１つの親イベントが、分散データベースのインスタンス内に識別子を有しておらず、かつ、（２）少なくとも１つの親イベントが、第１の作成済みラウンドしきい値を超える作成済みラウンド値に関連するときに満足される。第２の判断基準は、（１）第１の判断基準が満足されず、かつ、（２）親イベントの集合からの各親イベントが、第２の作成済みラウンドしきい値未満の作成済みラウンド値に関連するときに満足される。このプロセッサは、イベントが第１の判断基準または第２の判断基準に基づいて除外されなかったときに、分散データベースのインスタンス内にイベントを記憶するようにさらに構成される。

［１０２４］いくつかの実施形態では、装置は、計算デバイスの群に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの群内に含まれるように構成された第１の計算デバイスにある分散データベースのインスタンスに関連するメモリを含む。この装置は、メモリに動作可能に結合されたプロセッサを含む。プロセッサは、計算デバイスの群からの第２の計算デバイスによって定義されるイベントの群からのイベントの第１の集合の表示をメモリ内に記憶するように構成される。イベントの群からの各イベントは、（１）シーケンス値と（２）トランザクションの順序集合とに関連するバイトのシーケンスを含む。プロセッサは、同期化要求を複数の計算デバイスからの第３のデバイスに送るように構成される。同期化要求は、第１の識別子および第２の識別子を含む。第１の識別子は、イベントの第１の集合からの各残りのイベントに関連するシーケンス値未満のシーケンス値に関連するイベントの第１の集合からのイベントを識別する。第２の識別子は、イベントの第１の集合からの各残りのイベントに関連するシーケンス値を超えるシーケンス値に関連するイベントの第１の集合からのイベントを識別する。プロセッサは、同期化要求に応答して、第３の計算デバイスから、第２の計算デバイスによって定義されたイベントの群からのイベントの第２の集合を受信するように構成される。プロセッサは、イベントの第２の集合の表示をメモリ内に記憶するように構成される。イベントの第２の集合からの各イベントは、イベントの第１の集合には含まれない。プロセッサは、（１）イベント同意プロトコルと（２）イベントの第１の集合と（３）イベントの第２の集合とに基づいて、分散データベースのインスタンスの現在の状態を判定するように構成される。プロセッサは、現在の状態に関連するハッシュ値に基づいて、分散データベースのインスタンスの署名付き状態を生成するように構成される。ハッシュ値は、第１の計算デバイスに関連する秘密鍵を用いてデジタル署名される。プロセッサは、署名付き状態を示すトランザクションを含むイベントを分散データベースのインスタンスにポストするために信号を送るように構成される。プロセッサは、計算デバイスの群からの計算デバイスの集合から、署名付き状態を示すトランザクションを含むイベントに関連する合意の表示を受信するように構成される。プロセッサは、メモリから、合意の表示に基づいて、イベントの第１の集合の表示およびイベントの第２の集合の表示を除去するようにさらに構成される。

［１０２５］いくつかの実施形態では、装置は、計算デバイスの集合に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの集合内に含まれるように構成された第１の計算デバイスにある分散データベースのインスタンスを含む。この装置は、分散データベースのインスタンスを記憶するメモリに動作可能に結合されたプロセッサをも含む。このプロセッサは、第１の時刻に、イベントの第１の集合にリンクされた第１のイベントを定義するように構成される。このプロセッサは、第１の時刻の後の第２の時刻に、計算デバイスの集合からの第２の計算デバイスから、（１）第２の計算デバイスによって定義され、（２）イベントの第２の集合にリンクされた、第２のイベントを表す信号を受信するように構成される。このプロセッサは、少なくともプロトコルの結果に基づいてイベントの第３の集合に関連する順序を識別するように構成される。イベントの第１の集合またはイベントの第２の集合のうちの少なくとも１つからのイベントの第３の集合からの各イベント。プロセッサは、分散データベースのインスタンス内に、イベントの第３の集合に関連する順序を記憶するように構成される。

［１０２６］いくつかの例では、イベントの第３の集合からの各イベントは、属性（たとえば、シーケンス番号、世代番号、ラウンド番号、受信された番号、および／またはタイムスタンプなど）の集合に関連する。プロトコルの結果は、イベントの第３の集合からの各イベントの属性の集合からの各属性の値を含むことができる。属性の集合からの第１の属性の値は、第１の数値を含むことができ、属性の集合からの第２の属性の値は、第１の数値に関連する２進値を含むことができる。イベントの第３の集合からのイベントの第２の属性（たとえば、ラウンド増分値）の２進値は、そのイベントとそのイベントにリンクされたイベントの第４の集合との間の関係が判断基準（たとえば、そのイベントによって強く識別されるイベントの個数）を満足するかどうかに基づくものとすることができる。イベントの第４の集合からの各イベントは、（１）イベントの第３の集合からのイベントの先祖であり、（２）イベントの第４の集合からの残りのイベントとして第１の共通の属性（たとえば、共通のラウンド番号、ラウンドＲ第１イベントであることの表示など）に関連付けられる。第１の共通の属性は、計算デバイスの集合からの各計算デバイスによって定義されるイベントが第１の特定の値に関連付けられる第１のインスタンスを示すことができる（たとえば、ラウンドＲ第１イベントであることの表示など）。

［１０２７］属性の集合からの第３の属性（たとえば、受信されたラウンド番号）の値は、イベントとそのイベントにリンクされたイベントの第５の集合との間の関係に基づく第２の数値を含むことができる。イベントの第５の集合からの各イベントは、イベントの子孫であり、イベントの第５の集合からの残りのイベントとして第２の共通の属性（たとえば、有名）に関連する。第２の共通の属性は、（１）計算デバイスの集合からの各計算デバイスによって定義される第２のイベントが第１の特定の値とは異なる第２の特定の値に関連する第１のインスタンスを示す第３の共通の属性（たとえば、ラウンドＲ第１イベントまたは目撃者であること）と、（２）表示の集合に基づく結果とに関連付けられ得る。表示の集合からの各表示は、イベントの第６の集合からのイベントに関連付けられ得る。イベントの第６の集合からの各イベントは、計算デバイスの集合からの各計算デバイスによって定義される第３のイベントが第１の特定の値および第２の特定の値とは異なる第３の特定の値に関連する第１のインスタンスを示す第４の共通の属性に関連付けられ得る。いくつかの例では、第１の特定の値は、第１の整数（たとえば、第１のラウンド番号Ｒ）であり、第２の特定の値は、第１の整数より大きい第２の整数（たとえば、第２のラウンド番号Ｒ＋ｎ）であり、第３の特定の値は、第２の整数より大きい第３の整数（たとえば、第３のラウンド番号Ｒ＋ｎ＋ｍ）である。

［１０２８］いくつかの実施形態では、装置は、メモリおよびプロセッサを含む。メモリは、計算デバイスの集合に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの集合内に含まれるように構成された第１の計算デバイスにある分散データベースのインスタンスを含む。プロセッサは、分散データベースのインスタンスを記憶するメモリに動作可能に結合され、イベントの集合にリンクされたイベントを表す信号を受信するように構成される。プロセッサは、少なくともプロトコルの結果に基づいてイベントの集合に関連する順序を識別するように構成される。プロセッサは、分散データベースのインスタンス内に、イベントの集合に関連する順序を記憶するように構成される。

［１０２９］いくつかの実施形態では、非一時的プロセッサ可読媒体は、イベントの集合にリンクされたイベントを表す信号を受信し、イベントの集合からの各イベントに関連するラウンドと各イベントに関連するラウンドを増分すべき時の表示とに基づいてイベントの集合に関連する順序を識別するためにプロセッサによって実行される命令を表すコードを記憶する。コードは、さらに、プロセッサに、計算デバイスの集合に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの集合内に含まれるように構成された第１の計算デバイスにある分散データベースのインスタンス内に、イベントの集合に関連する順序を記憶させるコードをさらに含む。分散データベースのインスタンスは、プロセッサに動作可能に結合される。

［１０３０］いくつかの実施形態では、第１の計算デバイスにある分散データベースのインスタンスは、計算デバイスの集合に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの集合内に含まれるように構成され得る。第１の計算デバイスは、分散データベースのインスタンス内に複数のトランザクションを記憶する。データベース収束（ｄａｔａｂａｓｅｃｏｎｖｅｒｇｅｎｃｅ）モジュールが、第１の計算デバイスのメモリまたはプロセッサ内で実施され得る。データベース収束モジュールは、分散データベースのインスタンスに動作可能に結合され得る。データベース収束モジュールは、イベントの第１の集合にリンクされた第１のイベントを第１の時刻に定義するように構成され得る。イベントの第１の集合からの各イベントは、バイトのシーケンスであり、（１）トランザクションの複数の集合からのトランザクションの集合および（ｂ）トランザクションの集合に関連する順序に関連する。トランザクションの集合からの各トランザクションは、複数のトランザクションからのものである。データベース収束モジュールは、第１の時刻の後の第２の時刻に、計算デバイスの集合からの第２の計算デバイスから、（１）第２の計算デバイスによって定義され、（２）イベントの第２の集合にリンクされた第２のイベントを受信するように構成され得る。データベース収束モジュールは、第１のイベントおよび第２のイベントにリンクされた第３のイベントを定義するように構成され得る。データベース収束モジュールは、少なくともイベントの第１の集合およびイベントの第２の集合に基づいてイベントの第３の集合に関連する順序を識別するように構成され得る。イベントの第３の集合からの各イベントは、イベントの第１の集合またはイベントの第２の集合のうちの少なくとも１つからのものである。データベース収束モジュールは、少なくとも（１）イベントの第３の集合に関連する順序および（２）トランザクションの複数の集合からのトランザクションの各集合に関連する順序に基づいて、複数のトランザクションに関連する順序を識別するように構成され得る。データベース収束モジュールは、分散データベースのインスタンス内に、第１の計算デバイス内に記憶された複数のトランザクションに関連する順序を記憶するように構成され得る。

［１０３１］いくつかの実施形態では、第１の計算デバイスにある分散データベースのインスタンスは、計算デバイスの集合に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの集合内に含まれるように構成され得る。データベース収束モジュールは、第１の計算デバイスのメモリまたはプロセッサ内で実施され得る。データベース収束モジュールは、イベントの第１の集合にリンクされた第１のイベントを第１の時刻に定義するように構成され得る。イベントの第１の集合からの各イベントは、バイトのシーケンスである。データベース収束モジュールは、第１の時刻の後の第２の時刻に、計算デバイスの集合からの第２の計算デバイスから、（１）第２の計算デバイスによって定義され、（２）イベントの第２の集合にリンクされた第２のイベントを受信するように構成され得る。イベントの第２の集合からの各イベントは、バイトのシーケンスである。データベース収束モジュールは、第１のイベントおよび第２のイベントにリンクされた第３のイベントを定義するように構成され得る。データベース収束モジュールは、少なくともイベントの第１の集合およびイベントの第２の集合に基づいてイベントの第３の集合に関連する順序を識別するように構成され得る。イベントの第３の集合からの各イベントは、イベントの第１の集合またはイベントの第２の集合のうちの少なくとも１つからのものである。データベース収束モジュールは、分散データベースのインスタンス内に、イベントの第３の集合に関連する順序を記憶するように構成され得る。

［１０３２］いくつかの実施形態では、第１のトランザクションに関連するデータは、計算デバイスの集合に動作可能に結合されたネットワークを介して分散データベースを実施する計算デバイスの集合からの第１の計算デバイスで受信され得る。計算デバイスの集合からの各計算デバイスは、分散データベースの別々のインスタンスを有する。第１のトランザクションに関連する第１のトランザクション順序値は、第１の時刻に定義され得る。第２のトランザクションに関連するデータは、計算デバイスの集合からの第２の計算デバイスから受信され得る。トランザクションの集合は、第１の計算デバイスにある分散データベースのインスタンス内に記憶され得る。トランザクションの集合は、少なくとも第１のトランザクションおよび第２のトランザクションを含むことができる。少なくとも第１のトランザクション順序値および第２のトランザクション順序値を含むトランザクション順序値の集合は、第１の時刻の後の第２の時刻に選択され得る。第２のトランザクション順序値は、第２のトランザクションに関連付けられ得る。データベース状態変数は、少なくともトランザクションの集合およびトランザクション順序値の集合に基づいて定義され得る。

［１０３３］本明細書で使用されるときに、モジュールは、たとえば、特定の機能の実行に関連する動作可能に結合された電気構成要素の任意のアセンブリおよび／またはセットとすることができ、たとえば、メモリ、プロセッサ、電気トレース、光コネクタ、ソフトウェア（ハードウェア内で実行される）、および／または類似物を含むことができる。

［１０３４］本明細書で使用されるときに、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈がそうではないことを明瞭に規定しない限り、複数指示対象を含む。したがって、たとえば、用語「モジュール」は、単一のモジュールまたはモジュールの組合せを意味することが意図されている。たとえば、「ネットワーク」は、単一のネットワークまたはネットワークの組合せを意味することが意図されている。

［１０３５］図１は、一実施形態による、分散データベース・システム１００を示す高水準ブロック図である。図１は、４つの計算デバイス（計算デバイス１１０、計算デバイス１２０、計算デバイス１３０、および計算デバイス１４０）にまたがって実施される分散データベース１００を示すが、分散データベース１００が、図１に図示されていない計算デバイスを含む任意の個数の計算デバイスの集合を使用できることを理解されたい。ネットワーク１０５は、有線ネットワークおよび／または無線ネットワークとして実施され、計算デバイス１１０、１２０、１３０、１４０を動作可能に結合するのに使用される、任意のタイプのネットワーク（たとえば、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、仮想ネットワーク、遠隔通信ネットワーク）とすることができる。本明細書でさらに詳細に説明するように、いくつかの実施形態では、たとえば、計算デバイスは、インターネット・サービス・プロバイダ（ＩＳＰ）およびインターネット（たとえば、ネットワーク１０５）を介してお互いに接続されたパーソナル・コンピュータである。いくつかの実施形態では、接続は、ネットワーク１０５を介して、任意の２つの計算デバイス１１０、１２０、１３０、１４０の間で定義され得る。図１に示されているように、たとえば、接続は、計算デバイス１１０と、計算デバイス１２０、計算デバイス１３０、および計算デバイス１４０のうちの任意の１つとの間で定義され得る。

［１０３６］いくつかの実施形態では、計算デバイス１１０、１２０、１３０、１４０は、お互いと（たとえば、お互いへデータを送り、かつ／またはお互いからデータを受信する）ならびに中間ネットワークおよび／または代替ネットワーク（図１には図示せず）を介してネットワークと通信することができる。そのような中間ネットワークおよび／または代替ネットワークは、ネットワーク１０５と同一のタイプおよび／または異なるタイプを有するものとすることができる。

［１０３７］各計算デバイス１１０、１２０、１３０、１４０は、他の計算デバイスのうちの１つまたは複数にデータを送り、かつ／またはこれからデータを受信するためにネットワーク１０５を介してデータを送るように構成された任意のタイプのデバイスとすることができる。計算デバイスの例が、図１に示されている。計算デバイス１１０は、メモリ１１２、プロセッサ１１１、および出力デバイス１１３を含む。メモリ１１２は、たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、メモリ・バッファ、ハード・ドライブ、データベース、消去可能プログラム可能読取専用メモリ（ＥＰＲＯＭ）、電気的消去可能読取専用メモリ（ＥＥＰＲＯＭ）、読取専用メモリ（ＲＯＭ）、その他とすることができる。いくつかの実施形態では、計算デバイス１１０のメモリ１１２は、分散データベースのインスタンス（たとえば、分散データベース・インスタンス１１４）に関連するデータを含む。いくつかの実施形態では、メモリ１１２は、同期化イベントのレコード、他の計算デバイスとの以前の同期化イベントのレコード、同期化イベントの順序、イベント内のトランザクションの順序、同期化イベントおよび／またはトランザクションの順序の識別に関連するパラメータ、パラメータ（たとえば、トランザクションを定量化するデータベース・フィールド、イベントが発生する順序を定量化するデータベース・フィールド、および／またはその値がデータベース内に記憶され得る任意の他の適切なフィールド）の値を分散データベースの別のインスタンス（たとえば、計算デバイス１２０にある分散データベース・インスタンス１２４）に送ることおよび／またはこれから受信することに関連するモジュール、プロセス、および／または機能をプロセッサに実行させる命令を記憶する。

［１０３８］分散データベース・インスタンス１１４は、たとえば、データの記憶、変更、および／または削除を含めて、データを操作するように構成され得る。いくつかの実施形態では、分散データベース・インスタンス１１４は、リレーショナル・データベース、オブジェクト・データベース、ポスト・リレーショナル・データベース（ｐｏｓｔ−ｒｅｌａｔｉｏｎａｌｄａｔａｂａｓｅ）、および／または任意の他の適切なタイプのデータベースもしくはストレージとすることができる。たとえば、分散データベース・インスタンス１１４は、任意の特定の機能および／または産業に関するデータを記憶することができる。たとえば、分散データベース・インスタンス１１４は、特定の金融商品の所有権の履歴に関する値および／または値のベクトルを含む金融トランザクション（たとえば、計算デバイス１１０のユーザの）を記憶することができる。一般に、ベクトルは、パラメータの値の任意の集合とすることができ、パラメータは、異なる値をとることのできる任意のデータ・オブジェクトおよび／またはデータベース・フィールドとすることができる。したがって、分散データベース・インスタンス１１４は、それぞれが値のベクトルに関連付けられる、複数のパラメータおよび／またはフィールドを有することができる。値のベクトルは、そのデータベース・インスタンス１１４内のパラメータおよび／またはフィールドの実際の値を判定するのに使用される。いくつかの例では、分散データベース・インスタンス１１４は、同期化イベントのレコード、他の計算デバイスとの以前の同期化イベントのレコード、同期化イベントの順序、イベント内のトランザクションの順序、同期化イベントおよび／またはトランザクションの順序の識別に関連するパラメータおよび／または値（たとえば、本明細書で説明される同意方法を使用して順序を計算する際に使用される）、パラメータの値（たとえば、トランザクションを定量化するデータベース・フィールド、イベントが発生する順序を定量化するデータベース・フィールド、および／またはその値がデータベース内に記憶され得る任意の他の適切なフィールド）を記憶する。

［１０３９］いくつかの例では、分散データベース・インスタンス１１４は、データベース状態変数および／または現在の状態をも記憶することができる。現在の状態は、トランザクションの結果に関連する状態、差引勘定、条件、および／または類似物とすることができる。同様に言えば、状態は、トランザクションによって変更されるデータ構造および／または変数を含むことができる。他の例では、現在の状態は、別々のデータベース内および／またはメモリ１１２の一部内に記憶され得る。さらなる他の例では、現在の状態は、計算デバイス１１０とは異なる計算デバイスのメモリで記憶され得る。

［１０４０］いくつかの例では、分散データベース・インスタンス１１４は、（キー、値）対の集合など、他のデータ構造を実施するのにも使用され得る。分散データベース・インスタンス１１４によって記録されるトランザクションは、たとえば、（キー、値）対の集合内の（キー、値）対の追加、削除、または変更とすることができる。

［１０４１］いくつかの例では、分散データベース・システム１００または分散データベース・インスタンス１１４、１２４、１３４、１４４のいずれかが、照会され得る。たとえば、照会は、キーからなるものとすることができ、分散データベース・システム１００または分散データベース・インスタンス１１４、１２４、１３４、１４４から返される結果は、キーに関連する値とすることができる。いくつかの例では、分散データベース・システム１００または分散データベース・インスタンス１１４、１２４、１３４、１４４のいずれかは、トランザクションを介して変更されることも可能である。たとえば、データベースを変更するトランザクションは、変更トランザクションを認可する当事者によるデジタル署名を含むことができる。

［１０４２］分散データベース・システム１００は、たとえば、分散アイデンティティ・システム（ｄｉｓｔｒｉｂｕｔｅｄｉｄｅｎｔｉｔｙｓｙｓｔｅｍ）での様々なユーザに関連する属性の記憶など、多数の目的に使用され得る。たとえば、そのようなシステムは、「キー」としてユーザのアイデンティティを、「値」としてユーザに関連する属性のリストを使用することができる。いくつかの例では、アイデンティティは、そのユーザに既知の対応する秘密鍵を有する暗号公開鍵とすることができる。各属性は、たとえば、その属性をアサートする権利を有する機関によってデジタル署名され得る。各属性が、たとえば、その属性を読み取る権利を有する個人または個人のグループに関連する公開鍵を用いて暗号化されることも可能である。一部のキーまたは値が、そのキーまたは値を変更しまたは削除することを認可される当事者の公開鍵のリストを付加されることも可能である。

［１０４３］別の例では、分散データベース・インスタンス１１４は、ゲームプレイ・アイテムの現在の状態および所有権など、多人数同時参加型ゲーム（ＭａｓｓｉｖｅｌｙＭｕｌｔｉｐｌａｙｅｒＧａｍｅ、ＭＭＧ）に関するデータを記憶することができる。いくつかの例では、分散データベース・インスタンス１１４は、図１に示されているように、計算デバイス１１０内で実施され得る。他の例では、分散データベースのインスタンスは、計算デバイスによって（たとえば、ネットワークを介して）アクセス可能であるが、計算デバイス内では実施されない（図１には図示せず）。

［１０４４］計算デバイス１１０のプロセッサ１１１は、分散データベース・インスタンス１１４を走行させ、かつ／または実行するように構成された任意の適切な処理デバイスとすることができる。たとえば、本明細書でさらに詳細に説明するように、プロセッサ１１１は、計算デバイス１２０からの信号の受信に応答して分散データベース・インスタンス１１４を更新し、かつ／または計算デバイス１２０へ信号を送らせるように構成され得る。より具体的には、本明細書でさらに詳細に説明するように、プロセッサ１１１は、別の計算デバイスからのトランザクションに関連する同期化イベント、同期化イベントの順序に関連するレコード、および／または類似物の受信に応答して、分散データベース・インスタンス１１４を更新するためにモジュール、機能、および／またはプロセスを実行するように構成され得る。他の実施形態では、プロセッサ１１１は、分散データベースの別のインスタンス（たとえば、計算デバイス１２０の分散データベース・インスタンス１２４）内に記憶されたパラメータの値の受信に応答して分散データベース・インスタンス１１４を更新するためおよび／または計算デバイス１１０の分散データベース・インスタンス１１４内に記憶されたパラメータの値を計算デバイス１２０に送らせるために、モジュール、機能、および／またはプロセスを実行するように構成され得る。いくつかの実施形態では、プロセッサ１１１は、汎用プロセッサ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、および／または類似物とすることができる。

［１０４５］ディスプレイ１１３は、たとえば、液晶ディスプレイ（ＬＣＤ）、陰極線管ディスプレイ（ＣＲＴ）、または類似物など、任意の適切なディスプレイとすることができる。他の実施形態では、計算デバイス１１０、１２０、１３０、１４０のいずれもが、ディスプレイ１１３、１２３、１３３、１４３の代わりにまたはそれに加えて、別の出力デバイスを含む。たとえば、計算デバイス１１０、１２０、１３０、１４０のうちの任意の１つは、オーディオ出力デバイス（たとえば、スピーカ）、触覚出力デバイス、および／または類似物を含むことができる。さらなる他の実施形態では、計算デバイス１１０、１２０、１３０、１４０のうちのいずれもが、ディスプレイ１１３、１２３、１３３、１４３の代わりにまたはそれに加えて、入力デバイスを含む。たとえば、計算デバイス１１０、１２０、１３０、１４０のうちの任意の１つは、キーボード、マウス、および／または類似物を含むことができる。

［１０４６］計算デバイス１２０は、プロセッサ１２１、メモリ１２２、およびディスプレイ１２３を有し、これらは、それぞれプロセッサ１１１、メモリ１１２、およびディスプレイ１１３に構造的におよび／または機能的に類似するものとすることができる。また、分散データベース・インスタンス１２４は、分散データベース・インスタンス１１４に構造的におよび／または機能的に類似するものとすることができる。

［１０４７］計算デバイス１３０は、プロセッサ１３１、メモリ１３２、およびディスプレイ１３３を有し、これらは、それぞれプロセッサ１１１、メモリ１１２、およびディスプレイ１１３に構造的におよび／または機能的に類似するものとすることができる。また、分散データベース・インスタンス１３４は、分散データベース・インスタンス１１４に構造的におよび／または機能的に類似するものとすることができる。

［１０４８］計算デバイス１４０は、プロセッサ１４１、メモリ１４２、およびディスプレイ１４３を有し、これらは、それぞれプロセッサ１１１、メモリ１１２、およびディスプレイ１１３に構造的におよび／または機能的に類似するものとすることができる。また、分散データベース・インスタンス１４４は、分散データベース・インスタンス１１４に構造的におよび／または機能的に類似するものとすることができる。

［１０４９］計算デバイス１１０、１２０、１３０、１４０は、お互いに類似するものとして図示されているが、分散データベース・システム１００の各計算デバイスは、他の計算デバイスとは異なるものとすることができる。分散データベース・システム１００の各計算デバイス１１０、１２０、１３０、１４０は、たとえば、計算エンティティ（たとえば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、その他などのパーソナル・コンピューティング・デバイス）、携帯電話機、携帯情報端末（ＰＤＡ）などのうちの任意の１つとすることができる。たとえば、計算デバイス１１０は、デスクトップ・コンピュータとすることができ、計算デバイス１２０は、スマートフォンとすることができ、計算デバイス１３０は、サーバとすることができる。

［１０５０］いくつかの実施形態では、計算デバイス１１０、１２０、１３０、１４０の１つまたは複数の部分は、ハードウェアベースのモジュール（たとえば、デジタル信号プロセッサ（ＤＳＰ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ））および／またはソフトウェアベースのモジュール（たとえば、メモリ内に記憶され、かつ／またはプロセッサで実行されるコンピュータ・コードのモジュール）を含むことができる。いくつかの実施形態では、計算デバイス１１０、１２０、１３０、１４０に関連する機能のうちの１つまたは複数（たとえば、プロセッサ１１１、１２１、１３１、１４１に関連する機能）は、１つまたは複数のモジュール内に含まれ得る（たとえば、図２参照）。

［１０５１］計算デバイス（たとえば、計算デバイス１１０、１２０、１３０、１４０）のプロパティ、計算デバイスの個数、およびネットワーク１０５を含む分散データベース・システム１００のプロパティは、任意の個数の形で選択され得る。いくつかの例では、分散データベース・システム１００のプロパティは、分散データベース・システム１００の管理者によって選択され得る。他の例では、分散データベース・システム１００のプロパティは、分散データベース・システム１００のユーザによって集合的に選択され得る。

［１０５２］分散データベース・システム１００が使用されるので、リーダーが計算デバイス１１０、１２０、１３０、１４０の中で指名されることはない。具体的には、計算デバイス１１０、１２０、１３０、１４０のいずれもが、計算デバイス１１０、１２０、１３０、１４０の分散データベース・インスタンス１１１、１２、１３１、１４１、１４１内に記憶された値の間の論争を解決するためのリーダーとしては識別されず、かつ／または選択されない。その代わりに、本明細書で説明されるイベント同期化プロセス、投票プロセス、イベント同期化方法、および／または投票方法を使用して、計算デバイス１１０、１２０、１３０、１４０は、あるパラメータの値に集合的に収束することができる。

［１０５３］分散データベース・システム内でリーダーを有しないことは、分散データベース・システムのセキュリティを高める。具体的には、リーダーがあると、単一の攻撃点および／または故障点がある。悪意のあるソフトウェアが、リーダーに感染する、および／またはリーダーの分散データベース・インスタンスにあるパラメータの値が悪意を持って改変される場合には、故障および／または不正な値が、他の分散データベース・インスタンス全体に伝搬される。しかし、リーダーレス・システムには、単一の攻撃点および／または故障点がない。具体的には、リーダーレス・システムの分散データベース・インスタンス内のパラメータが、ある値を含む場合に、その値は、本明細書でさらに詳細に説明されるように、分散データベース・インスタンスがシステム内の他の分散データベース・インスタンスと値を交換した後に変化する。さらに、本明細書でさらに詳細に説明されるように、本明細書で説明されるリーダーレス分散データベース・システムは、収束の速度を高めると同時に、デバイスの間で送られるデータの量を減らす。

［１０５４］図２は、一実施形態による、分散データベース・システム（たとえば、分散データベース・システム１００）の計算デバイス２００を示す。いくつかの実施形態では、計算デバイス２００は、図１に関して図示され、説明された計算デバイス１１０、１２０、１３０、１４０に類似するものとすることができる。計算デバイス２００は、プロセッサ２１０およびメモリ２２０を含む。プロセッサ２１０およびメモリ２２０は、お互いに動作可能に結合される。いくつかの実施形態では、プロセッサ２１０およびメモリ２２０は、それぞれ、図１に関して図示され、詳細に説明されたプロセッサ１１１およびメモリ１１２に類似するものとすることができる。図２に示されているように、プロセッサ２１０は、データベース収束モジュール２１１および通信モジュール２１０を含み、メモリ２２０は、分散データベース・インスタンス２２１を含む。通信モジュール２１２は、計算デバイス２００が、他の計算デバイスと通信する（たとえば、これにデータを送り、かつ／またはこれからデータを受信する）ことを可能にする。いくつかの実施形態では、通信モジュール２１２（図１には図示せず）は、計算デバイス１１０が、計算デバイス１２０、１３０、１４０と通信することを可能にする。通信モジュール２１０は、たとえば、ネットワーク・インターフェース・コントローラ（ＮＩＣ）、無線接続、有線ポート、および／または類似物を含み、かつ／または使用可能にすることができる。したがって、通信モジュール２１０は、計算デバイス２００と別のデバイスとの間の通信セッション（たとえば、図１のネットワーク１０５またはインターネット（図示せず）を介する）を確立し、かつ／または維持することができる。同様に言えば、通信モジュール２１０は、計算デバイス２００が別のデバイスにデータを送り、かつ／またはこれからデータを受信することを可能にすることができる。

［１０５５］いくつかの例では、データベース収束モジュール２１１は、他のコンピューティング・デバイスとイベントおよび／またはトランザクションを交換し、データベース収束モジュール２１１が受信するイベントおよび／またはトランザクションを記憶し、イベントの間の参照のパターンによって定義される半順序に基づいてイベントおよび／またはトランザクションの順序付けを計算することができる。各イベントは、２つのより以前のイベントの暗号ハッシュ（そのイベントを２つのより以前のイベントおよびその先祖イベントにおよびその逆にリンクする）、ペイロード・データ（記録されるべきトランザクションなど）、現在時刻、その作成者が割り当てる、イベントが最初に定義された時刻であるタイムスタンプ（たとえば、日付およびＵＴＣ時刻）などの他の情報、および／または類似物を含むレコードとすることができる。いくつかの例では、あるメンバによって最初に定義されるイベントは、別のメンバによって定義された単一のイベントのハッシュだけを含む。そのような例では、メンバは、まだ以前の自己ハッシュ（たとえば、そのメンバによって以前に定義されたイベントのハッシュ）を有しない。いくつかの例では、分散データベース内の最初のイベントは、以前のイベントのハッシュを全く含まない（その分散データベースの以前のイベントがないので）。

［１０５６］いくつかの実施形態では、２つのより以前のイベントのそのような暗号ハッシュは、イベントを入力として使用する暗号ハッシュ関数に基づいて定義されたハッシュ値とすることができる。具体的には、そのような実施形態で、イベントは、バイトの特定のシーケンスまたはストリング（そのイベントの情報を表す）を含む。あるイベントのハッシュは、入力としてそのイベントのバイトのシーケンスを使用してハッシュ関数から返された値とすることができる。他の実施形態では、イベントに関連する任意の他の適切なデータ（たとえば、識別子、通し番号、イベントの特定の部分を表すバイトなど）は、そのイベントのハッシュを計算するためにハッシュ関数への入力として使用され得る。任意の適切なハッシュ関数が、ハッシュを定義するのに使用され得る。いくつかの実施形態では、各メンバは、所与のイベントに関して各メンバで同一のハッシュが生成されるように、同一のハッシュ関数を使用する。その後、イベントは、イベントを定義し、かつ／または作成するメンバによってデジタル署名され得る。

［１０５７］いくつかの例では、イベントおよびその相互接続の集合は、有向非巡回グラフ（ＤＡＧ）を形成することができる。いくつかの例では、ＤＡＧ内の各イベントは、２つのより以前のイベントを参照し（そのイベントを２つのより以前のイベントおよびその先祖イベントにおよびその逆にリンクする）、各参照は、厳密により以前のイベントへの参照であり、その結果、ループはない。いくつかの実施形態では、ＤＡＧは、暗号ハッシュに基づき、したがって、データ構造は、ハッシュグラフと呼ばれ得る（本明細書では「ｈａｓｈＤＡＧ」とも呼ばれる）。ハッシュグラフは、特定の順序を直接に符号化し、これは、ＹがＸのハッシュを含む場合、ＹがＸのハッシュを含むイベントのハッシュを含む場合、または任意の長さのそのような経路に関して、イベントＸがイベントＹの前にあることがわかることを意味する。しかし、ＸからＹへまたはＹからＸへの経路がない場合には、半順序は、どのイベントが最初に現れるのかを定義しない。したがって、データベース収束モジュールは、半順序から全順序を計算することができる。これは、計算デバイスによって使用される任意の適切な確定機能によって行われ得、その結果、計算デバイスは、同一の順序を計算するようになる。いくつかの実施形態では、各メンバは、各同期の後にこの順序を再計算することができ、最終的に、これらの順序は収束し、その結果、同意が出現できるようになる。

［１０５８］同意アルゴリズムは、ハッシュグラフ内のイベントの順序および／またはイベント内に記憶されたトランザクションの順序を判定するのに使用され得る。トランザクションの順序は、順序に従ってこれらのトランザクションを実行した結果としてデータベースの状態を定義することができる。データベースの定義された状態は、データベース状態変数として記憶され得る。

［１０５９］いくつかの例では、データベース収束モジュールは、ハッシュグラフ内の半順序から全順序を計算するのに以下の関数を使用することができる。他の計算デバイス（「メンバ」と呼ばれる）のそれぞれについて、データベース収束モジュールは、イベント（および／またはこれらのイベントの表示）がそのメンバによって受信された順序を発見するためにハッシュグラフを調べることができる。次に、データベース収束モジュールは、そのメンバが各イベントに数値「ランク」を割り当てたかのように計算することができ、ランクは、そのメンバが受信した最初のイベントに関して１、そのメンバが受信した２番目のイベントに関して２などである。データベース収束モジュールは、ハッシュグラフ内のメンバごとにこれを行うことができる。その後、イベントごとに、データベース収束モジュールは、割り当てられたランクの中央値を計算することができ、その中央値によってイベントをソートすることができる。ソートは、各メンバのデータベース収束モジュールが同一の方法を使用する場合に、２つの同点のイベントをそのハッシュの数値順によってソートすることによって、またはなんらかの他の方法によってなど、決定論的な形で同点を解決することができる。このソートの結果は、全順序である。

［１０６０］図６は、全順序を判定する一例のハッシュグラフ６４０を示す。ハッシュグラフ６４０は、２つのイベント（最も下方の縞を有する円および最も下方のドットを有する円）と、各メンバがこれらのイベントの表示を初めて受信した時刻（縞およびドットを有するその他の円）とを示す。最上部にある各メンバの名前は、どちらのイベントが自身の遅い順（ｓｌｏｗｏｒｄｅｒ）で最初であるかによって色分けされている。ドット付きのものより多数の縞付きの初期投票があり、したがって、メンバのそれぞれの同意投票は、縞付きである。言い換えると、メンバは、縞付きのイベントがドット付きのイベントの前に発生したことの合意に最終的に収束する。

［１０６１］この例では、メンバ（アリス、ボブ、キャロル、デイブ、およびエドというラベルを付けられた計算デバイス）は、イベント６４２またはイベント６４４のどちらが最初に発生したのかの同意を定義するために働く。各縞付きの円は、そこでメンバが最初にイベント６４４（および／またはそのイベント６４４の表示）を受信したイベントを示す。同様に、各ドット付きの円は、そこでメンバが最初にイベント６４２（および／またはそのイベント６４２の表示）を受信したイベントを示す。ハッシュグラフ６４０に示されているように、アリス、ボブ、およびキャロルは、それぞれ、イベント６４２の前にイベント６４４（および／またはイベント６４４の表示）を受信した。デイブとエドの両方は、イベント６４４（および／またはイベント６４４の表示）の前にイベント６４２（および／またはイベント６４２の表示）を受信した。したがって、より多数のメンバが、イベント６４２の前にイベント６４４を受信したので、全順序は、イベント６４４がイベント６４２の前に発生したことを示すように各メンバによって判定され得る。

［１０６２］他の例では、データベース収束モジュールは、ハッシュグラフ内の半順序から全順序を計算するのに異なる関数を使用することができる。そのような実施形態では、たとえば、データベース収束モジュールは、全順序を計算するのに以下の関数を使用することができ、ここで、正整数Ｑは、メンバによって共有されるパラメータである。
ｃｒｅａｔｏｒ（ｘ）＝イベントｘを作成したメンバ
ａｎｃ（ｘ）＝ｘ自体を含むｘの先祖であるイベントの集合
ｏｔｈｅｒ（ｘ）＝ｘが作成される直前に同期化された、メンバによって作成されたイベント
ｓｅｌｆ（ｘ）＝同一の作成者を有するｘの前の最後のイベント
ｓｅｌｆ（ｘ，０）＝ｓｅｌｆ（ｘ）
ｓｅｌｆ（ｘ，ｎ）＝ｓｅｌｆ（ｓｅｌｆ（ｘ），ｎ−１）
ｏｒｄｅｒ（ｘ，ｙ）＝ｋ、ただし、ｙは、ｃｒｅａｔｏｒ（ｘ）が学習したｋ番目のイベント
ｌａｓｔ（ｘ）＝｛ｙ｜ｙ∈ａｎｃ（ｘ）∧¬∃ｚ∈ａｎｃ（ｘ），（ｙ∈ａｎｃ（ｚ）∧ｃｒｅａｔｏｒ（ｙ）＝ｃｒｅａｔｏｒ（ｚ））｝

ｆａｓｔ（ｘ，ｙ）＝ソートされたリスト内のｙの位置。要素ｚ∈ａｎｃ（ｘ）は、
によってソートされ、同点は、各イベントのハッシュによって解決される。

［１０６３］この実施形態では、ｆａｓｔ（ｘ，ｙ）は、ｃｒｅａｔｏｒ（ｘ）の意見では、実質的にｘが作成されおよび／または定義された直後の、イベントの全順序でのｙの位置を与える。Ｑが無限大である場合には、上記は、前に説明した実施形態と同一の全順序を計算する。Ｑが有限であり、すべてのメンバがオンラインである場合には、上記は、前に説明した実施形態と同一の全順序を計算する。Ｑが有限であり、メンバの少数が所与の時刻にオンラインである場合には、この関数は、オンライン・メンバが、新しいメンバがゆっくりと１つずつオンラインになるときに変化しないままになる、オンライン・メンバの間での同意に達することを可能にする。しかし、ネットワークの区分がある場合には、各区分のメンバは、それら自体の同意に達する可能性がある。次に、区分が直されるときに、より小さい区分のメンバは、より大きい区分の同意を採用する。

［１０６４］さらなる他の例では、図８〜図１２Ｂに関して説明されるように、データベース収束モジュールは、ハッシュグラフ内の半順序から全順序を計算するのにさらなる異なる関数を使用することができる。図８〜図９に示されているように、各メンバ（アリス、ボブ、キャロル、デイブ、およびエド）は、イベント（図８に示された１４０１〜１４１３、図９に示された１５０１〜１５０６）を作成し、かつ／または定義する。図８〜図１２Ｂに関して説明される関数および副関数を使用することによって、イベントの全順序は、本明細書でさらに説明されるように、それらの受信されたラウンドによってイベントをソートし、それらの受信されたタイムスタンプによって同点を解決し、それらの署名によってこれらの同点を解決することによって、計算され得る。他の例では、イベントの全順序は、受信されたラウンドによってイベントをソートし、それらの受信された世代（それらの受信されたタイムスタンプではなく）によって同点を解決し、それらの署名によってこれらの同点を解決することによって、計算され得る。以下の段落は、イベントの順序を判定するために、イベントの受信されたラウンドと、イベントの受信された世代とを計算し、かつ／または定義するのに使用される関数を指定する。以下の項が、図８〜図１２Ｂに関連して使用され、図示される。

［１０６５］「親」イベントＸは、ＹがＸのハッシュを含む場合に、イベントＹの親である。たとえば、図８では、イベント１４１２の親は、イベント１４０６およびイベント１４０８を含む。

［１０６６］「先祖」イベントＸの先祖は、Ｘ、その親、その親の親などである。たとえば、図８では、イベント１４１２の先祖は、イベント１４０１、１４０２、１４０３、１４０６、１４０８、および１４１２である。あるイベントの先祖は、そのイベントにリンクされると言われ得、逆も同様である。

［１０６７］「子孫」イベントＸの子孫は、Ｘ、その子、その子の子などである。たとえば、図８では、イベント１４０１の子孫は、この図に示されたすべてのイベントである。別の例に関して、イベント１４０３の子孫は、イベント１４０３、１４０４、１４０６、１４０７、１４０９、１４１０、１４１１、１４１２、および１４１３である。あるイベントの子孫は、そのイベントにリンクされると言われ得、逆も同様である。

［１０６８］「Ｎ」母集団内のメンバの総数。たとえば、図８では、メンバは、アリス、ボブ、キャロル、デイブ、およびエドというラベルを付けられた計算デバイスであり、Ｎは５と等しい。

［１０６９］「Ｍ」Ｎのあるパーセンテージを超える（たとえば、Ｎの２／３を超える）最小の整数。たとえば、図８では、パーセンテージが２／３と定義される場合に、Ｍは４と等しい。他の例では、Ｍは、たとえば、Ｎの異なるパーセンテージ（たとえば、１／３、１／２など）、特定の事前定義の数、および／または任意の適切な形であるものとして定義され得る。

［１０７０］「自己親」イベントＸの自己親は、同一のメンバによって作成され、かつ／または定義されたその親イベントＹである。たとえば、図８では、イベント１４０５の自己親は１４０１である。

［１０７１］「自己先祖」イベントＸの自己先祖は、Ｘ、その自己親、その自己親の自己親などである。

［１０７２］「シーケンス番号」（または「ＳＮ」）（本明細書ではシーケンス値とも称する）イベントの自己親のシーケンス番号＋１と定義される、イベントの整数属性。たとえば、図８では、イベント１４０５の自己親は１４０１である。イベント１４０１のシーケンス番号が１なので、イベント１４０５のシーケンス番号は２（すなわち、１＋１）である。いくつかの実施態様では、シーケンス番号は、新しいラウンドの始めに再開始されまたは０にリセットされる。他の例では、シーケンス番号および／またはシーケンス値は、増分するのではなく減分することができ、辞書式順序を有する英数値（たとえば、Ａ、Ｂ、Ｃなど）とすることができ、かつ／または類似物とすることができる。

［１０７３］「世代番号」（または「ＧＮ」）イベントの親の世代番号の最大値＋１と定義される、イベントの整数属性。たとえば、図８では、イベント１４１２は、それぞれ世代番号４および２を有する２つの親、イベント１４０６および１４０８を有する。したがって、イベント１４１２の世代番号は、５（すなわち、４＋１）である。

［１０７４］「ラウンド増分」（または「ＲＩ」）０または１のいずれかとすることができる、イベントの属性。

［１０７５］「ラウンド番号」（または「ＲＮ」、本明細書では「作成済みラウンド」とも称する）イベントの整数属性。いくつかの例では、ラウンド番号は、イベントの親のラウンド番号の最大値＋イベントのラウンド増分と定義され得る。たとえば、図８では、イベント１４１２は、両方が１のラウンド番号を有する２つの親、イベント１４０６および１４０８を有する。イベント１４１２は、１のラウンド増分をも有する。したがって、イベント１４１２のラウンド番号は、２（すなわち、１＋１）である。他の例では、Ｒが、すべてがラウンド番号Ｒ−１を有する異なるメンバによって定義され、かつ／または作成された少なくともＭ個のイベントをイベントが強く見る（本明細書で説明される）ことができるようになる最小の整数である場合に、イベントは、ラウンド番号Ｒを有することができる。そのような整数がない場合には、イベントのラウンド番号は、デフォルト値（たとえば、０、１など）とすることができる。そのような例では、イベントのラウンド番号は、ラウンド増分を使用せずに計算され得る。たとえば、図８では、Ｍが、１／２×Ｎより大きい最小の整数になるように定義される場合に、Ｍは、３である。イベント１４１２は、Ｍ個のイベント１４０１、１４０２、および１４０８を強く見、このイベント１４０１、１４０２、および１４０８のそれぞれは、異なるメンバによって定義され、１のラウンド番号を有する。イベント１４１２は、異なるメンバによって定義された２のラウンド番号を有する少なくともＭ個のイベントを強く見ることができない。したがって、イベント１４１２のラウンド番号は２である。いくつかの例では、分散データベース内の最初のイベントは、１のラウンド番号を含む。他の例では、分散データベース内の最初のイベントは、０または任意の他の適切な数のラウンド番号を含むことができる。

［１０７６］「フォーキング」イベントＸおよびイベントＹが同一のメンバによって定義され、かつ／または作成され、どちらもが他方の自己先祖ではない場合に、イベントＸは、イベントＹとのフォークである。たとえば、図９では、メンバ・デイブは、イベント１５０３が、イベント１５０４の自己先祖ではなく、イベント１５０４が、イベント１５０３の自己先祖ではなくなるようにするために、両方が同一の自己親（すなわち、イベント１５０１）を有するイベント１５０３および１５０４を作成し、かつ／または定義することによってフォークする。

［１０７７］フォーキングの「識別」フォーキングは、お互いと共にフォークする２つのイベントの両方が、この２つのイベントの後で作成され、かつ／または定義された第３のイベントの先祖である場合に、第３のイベントによって「識別」され得る。たとえば、図９では、メンバ・デイブは、いずれもが他方の自己先祖ではないイベント１５０３および１５０４を作成することによってフォークする。このフォーキングは、より後のイベント１５０６によって識別され得る。というのは、イベント１５０３と１５０４との両方が、イベント１５０６の先祖であるからである。いくつかの例では、フォーキングの識別は、特定のメンバ（たとえば、デイブ）が不正をしたことを示すことができる。

［１０７８］イベントの「識別」イベントＸは、Ｘが、Ｙとのフォークである先祖イベントＺを有しない場合に、先祖イベントＹを「識別し」または「見る」。たとえば、図８では、イベント１４０３がイベント１４１２の先祖であり、イベント１４１２がイベント１４０３と共にフォークする先祖イベントを有しないので、イベント１４１２は、イベント１４０３を識別する（「見る」とも称する）。いくつかの例では、イベントＸは、ＸがイベントＹの前のフォーキングを識別しない場合に、イベントＹを識別することができる。そのような例では、イベントＸが、イベントＹを定義するメンバによるイベントＹの後のフォーキングを識別する場合であっても、イベントＸはイベントＹを見ることができる。イベントＸは、フォーキングの後のそのメンバによるイベントを識別しない。さらに、あるメンバが、両方がヒストリ内でそのメンバの最初のイベントである２つの異なるイベントを定義する場合に、イベントＸは、フォーキングを識別することができ、そのメンバによるすべてのイベントを識別しない。

［１０７９］イベントの「強い識別」（本明細書では「強く見ること」とも称する）イベントＸは、ＸがＹを識別する場合に、Ｘと同一のメンバによって作成され、かつ／または定義された先祖イベントＹを「強く識別する」（または「強く見る」）。イベントＸは、（１）ＸとＹとの両方を含み、（２）イベントＸの先祖であり、（３）先祖イベントＹの子孫であり、（４）Ｘによって識別され、（５）Ｙを識別でき、（６）少なくともＭ個の異なるメンバによって作成され、かつ／または定義される、イベントの集合Ｓが存在する場合に、Ｘと同一のメンバによって作成されず、かつ／または定義されない先祖イベントＹを「強く識別する」。たとえば、図８では、Ｍが、Ｎの２／３を超える最小の整数になるように定義される（すなわち、Ｍ＝１＋ｆｌｏｏｒ（２Ｎ／３）、この例では４になる）場合に、イベントの集合１４０１、１４０２、１４０６、および１４１２が、イベント１４１２の先祖であり、かつイベント１４０１の子孫である少なくとも４つのイベントの集合であり、これらが、それぞれ４つのメンバ、デイブ、キャロル、ボブ、およびエドによって作成され、かつ／または定義され、イベント１４１２が、イベント１４０１、１４０２、１４０６、および１４１２のそれぞれを識別し、イベント１４０１、１４０２、１４０６、および１４１２のそれぞれが、イベント１４０１を識別するので、イベント１４１２は、先祖イベント１４０１を強く識別する。同様にいえば、イベントＸ（たとえば、イベント１４１２）は、Ｘが異なるメンバによって作成されまたは定義された少なくともＭ個のイベント（たとえば、イベント１４０１、１４０２、１４０６、および１４１２）を見ることができ、それらのイベントのそれぞれがＹを見ることができる場合に、イベントＹ（たとえば、イベント１４０１）を「強く見る」ことができる。

［１０８０］「ラウンドＲ第１」イベント（本明細書では「目撃者」とも称する）イベントは、そのイベントが（１）ラウンド番号Ｒを有し、（２）Ｒ未満のラウンド番号を有する自己親を有するか、自己親を有しない場合に、「ラウンドＲ第１」イベント（または「目撃者」）である。たとえば、図８では、イベント１４１２は、２のラウンド番号を有し、その自己親がイベント１４０８であり、イベント１４０８が１のラウンド番号（すなわち、２未満）を有するので、「ラウンド２第１」イベントである。

［１０８１］いくつかの例では、イベントＸのラウンド増分は、Ｘが少なくともＭ個の「ラウンドＲ第１」イベントを識別し、Ｒがその親の最大ラウンド番号である場合に限って、１になると定義される。たとえば、図８では、Ｍが、１／２×Ｎより大きい最小の整数と定義される場合に、Ｍは３である。イベント１４１２は、そのすべてがラウンド１第１イベントであるＭ個のイベント１４０１、１４０２、および１４０８を強く識別する。１４１２の両方の親がラウンド１であり、１４１２が、少なくともＭ個のラウンド１第１を強く識別し、したがって、１４１２のラウンド増分は、１である。この図で「ＲＩ＝０」を用いてマークされたイベントのそれぞれは、少なくともＭ個のラウンド１第１を強く識別することができず、したがって、それらのラウンド増分は０である。

［１０８２］いくつかの例では、以下の方法が、イベントＸが先祖イベントＹを強く識別できるかどうかを判定するのに使用され得る。ラウンドＲ第１先祖イベントＹごとに、イベントＸの最小シーケンス番号を与える、１メンバあたり１つの整数の配列Ａ１を維持し、ここで、そのメンバは、イベントＸを作成し、かつ／または定義し、ＸはＹを識別することができる。イベントＺごとに、ＺがＷを識別できるように、１メンバあたり１つの、そのメンバによって作成されかつ／または定義されたイベントＷの最大シーケンス番号を与える整数の配列Ａ２を維持する。Ｚが先祖イベントＹを強く識別できるかどうかを判定するために、Ａ１［Ｅ］≦Ａ２［Ｅ］になる要素位置Ｅの個数をカウントする。イベントＺは、このカウントがＭを超える場合に限って、Ｙを強く識別することができる。たとえば、図８では、メンバ、アリス、ボブ、キャロル、デイブ、およびエドは、それぞれがイベント１４０１を識別でき、ここで、それを行える最も早期のイベントは、それぞれイベント｛１４０４，１４０３，１４０２，１４０１，１４０８｝である。これらのイベントは、シーケンス番号Ａ１＝｛１，１，１，１，１｝を有する。同様に、イベント１４１２によって識別される、それらのそれぞれによる最も遅いイベントは、イベント｛なし，１４０６，１４０２，１４０１，１４１２｝であり、アリスは、１４１２がアリスによるどのイベントをも識別できないので、「なし」としてリストされている。これらのイベントは、それぞれＡ２＝｛０，２，１，１，２｝のシーケンス番号を有し、ここで、すべてのイベントが、正のシーケンス番号を有し、したがって、０は、アリスが１４１２によって識別されるイベントを有しないことを意味する。リストＡ１をリストＡ２と比較することによって、結果｛１≦０，１≦２，１≦１，１≦１，１≦２｝が与えられ、これは、真である４つの値を有する｛偽，真，真，真，真｝と同等である。したがって、１４１２の先祖および１４０１の子孫である４つのイベントの集合が存在する。４は、少なくともＭであり、したがって、１４１２は、１４０１を強く識別する。

［１０８３］Ａ１およびＡ２を用いて、イベントＸが先祖イベントＹを強く識別するかどうかを判定する方法の実施に関するさらに別の変形形態は、次のとおりである。両方の配列内の整数要素が１２８未満である場合には、各要素を単一のバイト内に記憶し、８個のそのような要素を単一の６４ビット語にパックし、Ａ１およびＡ２をそのような語の配列にすることが可能である。Ａ１内の各バイトの最上位ビットは、０をセットされ得、Ａ２内の各バイトの最上位ビットは、１をセットされ得る。２つの対応する語を減算し、次に、最上位ビット以外のすべてを０にするためにマスクとのビット単位ＡＮＤを実行し、次に、７ビット位置だけ右シフトして、Ｃプログラミング言語で（（Ａ２［ｉ］−Ａ１［ｉ］）＆０ｘ８０８０８０８０８０８０８０８０）＞＞７）と表される値を得る。これが、０に初期化されたランニング・アキュムレータ（ｒｕｎｎｉｎｇａｃｃｕｍｕｌａｔｏｒ）Ｓに加算され得る。これを複数回行った後に、バイトをシフトし、加算することによってアキュムレータをカウントに変換して、（（Ｓ＆０ｘｆｆ）＋（（Ｓ＞＞８）＆０ｘｆｆ）＋（（Ｓ＞＞１６）＆０ｘｆｆ）＋（（Ｓ＞＞２４）＆０ｘｆｆ）＋（（Ｓ＞＞３２）＆０ｘｆｆ）＋（（Ｓ＞＞４０）＆０ｘｆｆ）＋（（Ｓ＞＞４８）＆０ｘｆｆ）＋（（Ｓ＞＞５６）＆０ｘｆｆ））を得る。いくつかの例では、これらの計算は、Ｃ、Ｊａｖａ、および／または類似物などのプログラミング言語で実行され得る。他の例では、この計算は、ＩｎｔｅｌおよびＡＭＤによって提供されるＡｄｖａｎｃｅｄＶｅｃｔｏｒＥｘｔｅｎｓｉｏｎｓ（ＡＶＸ）命令または、グラフィックス処理ユニット（ＧＰＵ）もしくは汎用グラフィックス処理ユニット（ＧＰＧＰＵ）内の同等物などのプロセッサ固有命令を使用して実行され得る。いくつかのアーキテクチャでは、この計算は、１２８ビット、２５６ビット、５１２ビット、またはより多数のビットなど、６４ビットより長い語を使用することによって、より高速に実行され得る。

［１０８４］「有名な」イベントラウンドＲイベントＸは、（１）イベントＸが「ラウンドＲ第１」イベント（または「目撃者」）であり、（２）下で説明するように、ビザンチン合意プロトコルの実行を介して「肯定」の決定に達する場合に、「有名」である。いくつかの実施形態では、ビザンチン合意プロトコルは、分散データベースのインスタンス（たとえば、分散データベース・インスタンス１１４）および／またはデータベース収束モジュール（たとえば、データベース収束モジュール２１１）によって実行され得る。たとえば、図８では、５つのラウンド１第１すなわち１４０１、１４０２、１４０３、１４０４、および１４０８が図示されている。Ｍが、１／２×Ｎ（３である）より大きい最小の整数と定義される場合に、１４１２は、ラウンド２第１である。プロトコルがより長く走行する場合に、ハッシュグラフは、上向きに成長し、最終的に、他の４つのメンバも、この図の最上部の上にラウンド２第１を有する。各ラウンド２第１は、ラウンド１第１のそれぞれが「有名」であるかどうかに関する「票」を有する。イベント１４１２は、１４０１、１４０２、および１４０３が有名であることに関して肯定を投票する。というのは、これらが、イベント１４１２が識別できるラウンド１第１であるからである。イベント１４１２は、１４０４を識別できないので、１４０４が有名であることに関して否定を投票する。１４０２など、所与のラウンド１第１に関して、「有名」であるか否かのその状況は、それが有名であるか否かに関する各ラウンド２第１の票を計算することによって決定される。これらの票は、その後、ラウンド３第１に伝搬し、その後、１４０２が有名であったかどうかに関する合意に最終的に達するまで、ラウンド４第１などに伝搬する。同一のプロセスが、他の第１に関して繰り返される。

［１０８５］ビザンチン合意プロトコルは、「有名」なイベントを識別するために、「ラウンドＲ第１」イベントの票および／または決定を収集し、使用することができる。たとえば、「ラウンドＲ＋１第１」Ｙは、ＹがイベントＸを「識別」できる場合には「肯定」を投票し、そうでない場合には「否定」を投票する。その後、票は、いずれかのメンバによって決定に達するまで、ラウンドＧごとに計算され、Ｇ＝Ｒ＋２、Ｒ＋３、Ｒ＋４などである。決定に達するまで、票が、ラウンドＧごとに計算される。これらのラウンドの一部は、「過半数」ラウンドとすることができ、一部の他のラウンドは、「硬貨」ラウンドとすることができる。いくつかの例では、たとえば、ラウンドＲ＋２が過半数ラウンドであり、将来のラウンドは、過半数ラウンドまたは硬貨ラウンドのいずれかとして指定される（たとえば、事前定義のスケジュールに従って）。たとえば、いくつかの例では、将来のラウンドが過半数ラウンドまたは硬貨ラウンドのどちらであるのかは、２つの連続する硬貨ラウンドが存在し得ないという条件に従って、任意に判定され得る。たとえば、５つの過半数ラウンドがあり、その後に１つの硬貨ラウンドがあり、その後に５つの過半数ラウンドがあり、その後に１つの硬貨ラウンドがあり、合意に達するのに必要である限りこれが繰り返されると事前に定義することができる。

［１０８６］いくつかの例では、ラウンドＧが過半数ラウンドである場合に、票は、次のように計算され得る。Ｖを投票する（Ｖは、「肯定」または「否定」のいずれかである）少なくともＭ個のラウンドＧ−１第１を強く識別するラウンドＧイベントが存在する場合には、同意決定はＶであり、ビザンチン合意プロトコルは終了する。そうではない場合には、各ラウンドＧ第１イベントは、各ラウンドＧ第１イベントが強く識別できるラウンドＧ−１第１の過半数である新しい票を計算する。過半数ではなく同点がある例では、票は、「肯定」と指定され得る。

［１０８７］同様に言えば、ＸがラウンドＲ目撃者（またはラウンドＲ第１）である場合に、ラウンドＲ＋１、Ｒ＋２などでの投票の結果が計算され得、ここで、各ラウンドの目撃者は、Ｘが有名であるかどうかに関して投票している。ラウンドＲ＋１では、Ｘを見ることのできるすべての目撃者が、肯定を投票し、他の目撃者は、否定を投票する。ラウンドＲ＋２では、すべての目撃者は、それが強く見ることのできるラウンドＲ＋１目撃者の票の過半数に従って投票する。同様に、ラウンドＲ＋３では、すべての目撃者は、それが強く見ることのできるラウンドＲ＋２目撃者の票の過半数に従って投票する。これは、複数のラウンドにわたって継続することができる。同点の場合には、票は、肯定にセットされ得る。他の例では、同点は、否定にセットされ得、あるいは、ランダムにセットされ得る。いずれかのラウンドが、少なくともＭ個の否定を投票する目撃者を有する場合に、選挙が終了し、Ｘは有名ではない。いずれかのラウンドが、少なくともＭ個の肯定を投票する目撃者を有する場合に、選挙が終了し、Ｘは有名である。肯定および否定の両方が少なくともＭ個の票を有しない場合には、選挙は、次のラウンドに継続する。

［１０８８］一例として、図８で、示された図の下にあるいくつかのラウンド第１イベントＸを検討されたい。各ラウンド１第１は、Ｘが有名であるかどうかに関する票を有する。イベント１４１２は、ラウンド１第１イベント１４０１、１４０２、および１４０８を強く識別することができる。したがって、その票は、それらの票に基づく。これが過半数ラウンドである場合には、１４１２は、｛１４０１，１４０２，１４０８｝のうちの少なくともＭ個が肯定の票を有するかどうかをチェックする。そうである場合には、決定は肯定であり、合意に達している。それらのうちの少なくともＭ個が否定を投票する場合には、決定は否定であり、合意に達している。投票が、どの方向でも少なくともＭ個を有しない場合には、１４１２は、１４０１、１４０２、および１４０８のそれらの票の過半数である票を与えられる（同点である場合には、肯定を投票することによって同点を解決する）。その後、その票は、次のラウンドで使用され、合意に達するまで継続する。

［１０８９］いくつかの例では、ラウンドＧが硬貨ラウンドである場合に、票は、次のように計算され得る。イベントＸが、Ｖを投票する（Ｖは、「肯定」または「否定」のいずれかである）少なくともＭ個のラウンドＧ−１第１を識別できる場合には、イベントＸは、その票をＶに変更する。そうではなく、ラウンドＧが硬貨ラウンドである場合には、各ラウンドＧ第１イベントＸは、その票を、イベントＸの署名の最下位ビットと定義される擬似ランダム判定の結果に変更する（いくつかの例で硬貨の反転に似る）。

［１０９０］同様に言えば、そのような例で、選挙がラウンドＲ＋Ｋ（硬貨ラウンド）に達する場合に（Ｋは指定された係数（たとえば、３、６、７、８、１６、３２などの数の倍数または任意の他の適当な数）である）、選挙は、そのラウンドでは終了しない。選挙がこのラウンドに達する場合に、選挙は、少なくとももう１ラウンドだけ継続することができる。そのようなラウンドでは、イベントＹがラウンドＲ＋Ｋ目撃者である場合に、イベントＹが、Ｖを投票するラウンドＲ＋Ｋ−１からの少なくともＭ個の目撃者を強く見ることができるならば、ＹはＶを投票する。そうではない場合には、Ｙは、ランダムな値に従って投票する（たとえば、イベントＹの署名の１ビット（たとえば、最下位ビット、最上位ビット、ランダムに選択されたビット）に従って、ただし、１＝肯定、０＝否定またはその逆、イベントＹのタイムスタンプに従って、暗号「共有硬貨」プロトコルおよび／または任意の他のランダム判定を使用して）。このランダム判定は、Ｙが作成される前には予測不能であり、したがって、イベントおよび同意プロトコルのセキュリティを高めることができる。

［１０９１］たとえば、図８で、ラウンド２が硬貨ラウンドであり、投票が、ラウンド１の前のあるイベントが有名であったかどうかに関するものである場合に、イベント１４１２は、まず、｛１４０１，１４０２，１４０８｝のうちの少なくともＭ個が肯定を投票し、またはそのうちの少なくともＭ個が否定を投票したかどうかをチェックする。そうである場合には、１４１２は、同一の形で投票する。いずれかの方向に投票する少なくともＭ個がない場合には、１４１２は、ランダムまたは擬似ランダムな票を有する（たとえば、エドがイベント１４１２に署名した時、彼がこれを作成した時、および／または彼がこれを定義したときにエドがイベント１４１２のために作成したデジタル署名の最下位ビットに基づく）。

［１０９２］いくつかの例では、擬似ランダム判定の結果は、暗号共有硬貨プロトコルの結果とすることができ、これは、たとえば、ラウンド番号のしきい署名の最下位ビットとして実施され得る。

［１０９３］システムが、上で説明した擬似ランダム判定の結果を計算する方法のうちの任意の１つから構築され得る。いくつかの例では、システムは、ある順序で異なる方法を通ってサイクルする。他の例では、システムは、事前定義のパターンに従って異なる方法の間で選択することができる。

［１０９４］「受信されたラウンド」Ｒが、ラウンド番号Ｒを有する有名なラウンドＲ第１イベント（または有名な目撃者）の少なくとも半分がＸの子孫になり、かつ／またはＸを見ることができるようになる最小の整数である場合に、イベントＸは、Ｒの「受信されたラウンド」を有する。他の例では、任意の他の適切なパーセンテージが使用され得る。たとえば、別の例では、Ｒが、ラウンド番号Ｒを有する有名なラウンドＲ第１イベント（または有名な目撃者）の少なくとも所定のパーセンテージ（たとえば、４０％、６０％、８０％など）がＸの子孫になり、かつ／またはＸを見ることができるようになる最小の整数である場合に、イベントＸは、Ｒの「受信されたラウンド」を有する。

［１０９５］いくつかの例では、イベントＸの「受信された世代」は、次のように計算され得る。どのメンバが、イベントＸを識別できる各ラウンドＲ第１イベントを作成し、かつ／または定義したのかを見つける。次に、Ｘを識別できるそのメンバによる最も古いイベントの世代番号を判定する。次に、そのリストの中央値になるようにＸの「受信された世代」を定義する。

［１０９６］いくつかの例では、イベントＸの「受信されたタイムスタンプ」Ｔは、Ｘを識別し、かつ／または見る、各メンバによる最初のイベントを含むイベント内のタイムスタンプの中央値とすることができる。たとえば、イベント１４０１の受信されたタイムスタンプは、イベント１４０２、１４０３、１４０３、および１４０８のタイムスタンプの値の中央値とすることができる。いくつかの例では、イベント１４０１のタイムスタンプは、中央値計算に含められ得る。他の例では、Ｘの受信されたタイムスタンプは、Ｘを識別するか見る各メンバによる最初のイベントであるイベント内の任意の他の値またはタイムスタンプの値の組合せとすることができる。たとえば、Ｘの受信されたタイムスタンプは、タイムスタンプの平均値、タイムスタンプの標準偏差、変更された平均値（たとえば、最も古いタイムスタンプおよび最も新しいタイムスタンプを計算から除去することによって）、および／または類似物に基づくものとすることができる。さらなる他の例では、拡張された中央値が使用され得る。

［１０９７］いくつかの例では、イベントの全順序および／または同意順序は、イベントをその受信されたラウンドによってソートし、その受信されたタイムスタンプによって同点を解決し、その署名によって同点を解決することによって計算される。他の例では、イベントの全順序は、イベントをその受信されたラウンドによってソートし、その受信された世代によって同点を解決し、その署名によって同点を解決することによって計算され得る。前述の段落は、イベントの受信されたラウンド、受信されたタイムスタンプ、および／または受信された世代を計算し、かつ／または定義するのに使用される関数を指定する。

［１０９８］他の例では、各イベントの署名を使用するのではなく、同一の受信されたラウンドおよび／またはそのラウンド内の同一の受信された世代を有する有名なイベントまたは有名な目撃者の署名との排他的論理和をとられたそのイベントの署名が使用され得る。他の例では、イベント署名の任意の他の適当な組合せが、イベントの同意順序を定義するために同点を解決するのに使用され得る。

［１０９９］さらなる他の例では、リストの中央値として「受信された世代」を定義するのではなく、「受信された世代」は、リスト自体になるように定義され得る。次に、受信された世代によってソートするときに、２つの受信された世代は、そのリストの中央要素によって比較され得、同点は中央の直前の要素によって解決され、同点は中央の直後の要素によって解決され、同点が解決されるまで、これまでに使用された要素の前の要素と後の要素との間で交番することによって継続する。

［１１００］いくつかの例では、中央値タイムスタンプは、「拡張された中央値」に置換され得る。そのような例では、タイムスタンプのリストは、単一の受信されたタイムスタンプではなく、イベントごとに定義され得る。イベントＸのタイムスタンプのリストは、Ｘを識別し、かつ／または見る、各メンバによる最初のイベントを含むことができる。たとえば、図８では、イベント１４０１のタイムスタンプのリストは、イベント１４０２、１４０３、１４０３、および１４０８のタイムスタンプを含むことができる。いくつかの例では、イベント１４０１のタイムスタンプも含められ得る。タイムスタンプのリストを用いて同点を解決する（すなわち、２つのイベントが同一の受信されたラウンドを有する）ときには、各イベントのリストの中央タイムスタンプ（または、偶数の長さを有する場合に、２つの中央タイムスタンプの第１または第２のうちの所定のタイムスタンプ）が比較され得る。これらのタイムスタンプが同一である場合には、中央タイムスタンプの直後のタイムスタンプが、比較され得る。これらのタイムスタンプが同一である場合には、中央タイムスタンプの直前のタイムスタンプが、比較され得る。これらのタイムスタンプも同一である場合には、３つの既に比較されたタイムスタンプの後のタイムスタンプが比較される。これは、同点が解決されるまで交番し続けることができる。上の議論に似て、２つのリストが同一である場合には、同点は、２つの要素の署名によって解決され得る。

［１１０１］さらなる他の例では、「切り詰められた拡張された中央値」が、「拡張された中央値」の代わりに使用され得る。そのような例では、タイムスタンプのリスト全体が、イベントごとに記憶されるのではない。その代わりに、リストの中央付近の少数の値だけが、記憶され、比較に使用される。

［１１０２］受信された中央値タイムスタンプは、イベントの全順序の計算に加えて、他の目的にも潜在的に使用され得る。たとえば、ボブは、アリスが同一の契約に署名するトランザクションを含むイベントＸがあり、Ｘの受信されたタイムスタンプが、ある締切期限またはその前である場合に限って、ボブが契約によって束縛されることに合意すると述べる契約に署名する場合がある。その場合に、ボブは、上で説明した「受信された中央値タイムスタンプ」によって示されるように、アリスが締切期限の後に署名する場合に、その契約によっては束縛されないはずである。

［１１０３］いくつかの例では、分散データベースの状態は、同意に達した後に定義され得る。たとえば、Ｓ（Ｒ）が、ラウンドＲ内の有名な目撃者によって見られ得るイベントの集合である場合に、最終的に、Ｓ（Ｒ）内のイベントのすべてが、既知の受信されたラウンドおよび受信されたタイムスタンプを有する。その点で、Ｓ（Ｒ）内のイベントの同意順序は、既知であり、変化しない。この点に達した後に、メンバは、イベントおよびその順序の表現を計算し、かつ／または定義することができる。たとえば、メンバは、Ｓ（Ｒ）内のイベントのハッシュ値をその同意順序で計算することができる。その後、メンバは、ハッシュ値にデジタル署名し、そのメンバが定義する次のイベント内にそのハッシュ値を含めることができる。これは、Ｓ（Ｒ）内のイベントが、変化しない所与の順序を有するとそのメンバが判定したことを他のメンバに知らせるのに使用され得る。メンバのうちの少なくともＭ個（または任意の他の適切な個数もしくはメンバのパーセンテージ）がＳ（Ｒ）のハッシュ値に署名した（かつ、したがってハッシュ値によって表される順序に合意した）後に、イベントの同意リストは、メンバの署名のリストと一緒に、同意順序がＳ（Ｒ）内のイベントに関して主張されたとおりであることを照明するのに使用され得る単一のファイル（または他のデータ構造）を形成することができる。他の例では、イベントが、分散データベース・システムの状態を更新するトランザクションを含む（本明細書で説明するように）場合に、ハッシュ値は、Ｓ（Ｒ）内のイベントのトランザクションを同意順序で適用した後の分散データベース・システムの状態のハッシュ値とすることができる。分散データベースの状態に関するさらなる詳細は、図１３を参照して議論される。

［１１０４］いくつかの例では、Ｍ（上で説明した）は、単に全メンバの個数の分数、パーセンテージ、および／または値であるのではなく、各メンバに割り当てられた重み値に基づくものとすることができる。そのような例では、各メンバは、分散データベース・システム内でのその関心および／または影響に関連するステークを有する。そのようなステークは、重み値とすることができる。そのメンバによって定義された各イベントは、その定義するメンバの重み値を有すると言われ得る。次に、Ｍは、全メンバの総ステークの分数とすることができる。Ｍに依存するものとして上で説明されたイベントは、少なくともＭ個のステーク和を有するメンバの集合が合意するときに発生する。したがって、そのステークに基づいて、ある種のメンバは、システムと同意順序がどのように導出されるのかとに対するより大きい影響を有することができる。いくつかの例では、あるイベント内のトランザクションは、１つまたは複数のメンバのステークを変更し、新しいメンバを追加し、かつ／またはメンバを削除することができる。そのようなトランザクションが、Ｒの受信されたラウンドを有する場合に、受信されたラウンドが計算された後に、ラウンドＲ目撃者の後のイベントは、変更されたステークおよびメンバの変更されたリストを使用して、そのラウンド番号および他の情報を再計算する。ラウンドＲイベントが有名であるかどうかに関する投票は、古いステークおよびメンバ・リストを使用するが、Ｒの後のラウンドに関する投票は、新しいステークおよびメンバ・リストを使用する。同意を判定するための重み値の使用に関する追加の詳細は、参照によってその全体が本明細書に組み込まれている、２０１６年１２月２１日に出願した米国特許出願第１５／３８７０４８号、名称「ＭｅｔｈｏｄｓＡｎｄＡｐｐａｒａｔｕｓＦｏｒＡＤｉｓｔｒｉｂｕｔｅｄＤａｔａｂａｓｅＷｉｔｈｉｎＡＮｅｔｗｏｒｋ」、現在は米国特許第９６４６０２９号に記載されている。

［１１０５］前述の項、定義、およびアルゴリズムは、図８〜図１２Ｂで説明される実施形態および概念を例示するのに使用される。図１０Ａおよび図１０Ｂは、数学的な形で示された同意方法および／またはプロセスの例のアプリケーションを示す。図１１Ａおよび図１１Ｂは、数学的な形で示された同意方法および／またはプロセスの第２の例のアプリケーションを示し、図１２Ａおよび図１２Ｂは、数学的な形で示された同意方法および／またはプロセスの第３の例のアプリケーションを示す。

［１１０６］図２では、データベース収束モジュール２１１および通信モジュール２１２が、図２ではプロセッサ２１０内で実施されるものとして図示されている。他の実施形態では、データベース収束モジュール２１１および／または通信モジュール２１２は、メモリ２２０内で実施され得る。さらなる他の実施形態では、データベース収束モジュール２１１および／または通信モジュール２１２は、ハードウェアベースとされ得る（たとえば、ＡＳＩＣ、ＦＰＧＡなど）。いくつかの実施形態では、分散データベース・インスタンス２２１は、図１に示された分散データベース・システム１００の分散データベース・インスタンス１１４、１２４、１３４、１４４に類似するものとすることができる。

［１１０７］図７は、一実施形態による、２つの計算デバイス同期化イベントの信号フロー図を示す。具体的には、いくつかの実施形態で、分散データベース・インスタンス７０３および８０３は、収束を得るためにイベントを交換することができる。計算デバイス７００は、ランダムに、計算デバイス７００との関係に基づいて、計算デバイス７００への近接に基づいて、計算デバイス７００に関連する順序付きリストに基づいて、および／または類似物によって、計算デバイス８００との同期化を選択することができる。いくつかの実施形態では、計算デバイス８００が、分散データベース・システムに属する計算デバイスの集合から計算デバイス７００によって選択され得るので、計算デバイス７００は、複数回連続して計算デバイス８００を選択することができ、あるいは、暫くの間、計算デバイス８００を選択しないものとすることができる。他の実施形態では、以前に選択された計算デバイスの表示が、計算デバイス７００で記憶され得る。そのような実施形態では、計算デバイス７００は、計算デバイス８００をもう一度選択できるようになる前に、所定の回数の選択を待つことができる。上で説明したように、分散データベース・インスタンス７０３および８０３は、それぞれ計算デバイス７００のメモリ内および計算デバイス８００のメモリ内で実施され得る。

［１１０８］図３〜図６は、一実施形態による、ハッシュグラフの例を示す。５つのメンバがあり、そのそれぞれが、暗い垂直線によって表される。各円は、イベントを表す。あるイベントからの２つの下向きの線は、２つの以前のイベントのハッシュを表す。この例のすべてのイベントは、各メンバの最初のイベントを除いて、２つの下向きの線（同一のメンバへの１つの暗い線および別のメンバへの１つの明るい線）を有する。時刻は、上向きに進行する。図３〜図６では、分散データベースの計算デバイスは、アリス、ボブ、キャロル、デイブ、およびエドとして示される。そのような表示が、図１に示されこれに関して説明された計算デバイス１１０、１２０、１３０、および１４０に構造的および機能的に類似する計算デバイスを指すことを理解されたい。

［１１０９］例のシステム１計算デバイス７００がアリスと呼ばれ、計算デバイス８００がボブと呼ばれる場合に、これらの間の同期化は、図７に示されたものとすることができる。アリスとボブとの間の同期化は、次のようなものとすることができる。

［１１１０］ −アリスが、分散データベース７０３内に記憶されたイベントをボブに送る。

［１１１１］ −ボブが、以下を含む新しいイベントを作成し、かつ／または定義する

［１１１２］ −−ボブが作成し、かつ／または定義した最後のイベントのハッシュ

［１１１３］ −−アリスが作成し、かつ／または定義した最後のイベントのハッシュ

［１１１４］ −−上記の、ボブによるデジタル署名

［１１１５］ −ボブが、分散データベース・インスタンス８０３内に記憶されたイベントをアリスに送る。

［１１１６］ −アリスが、新しいイベントを作成し、かつ／または定義する。

［１１１７］ −アリスが、そのイベントをボブに送る

［１１１８］ −アリスが、ハッシュグラフの関数としてイベントの全順序を計算する

［１１１９］ −ボブが、ハッシュグラフの関数としてイベントの全順序を計算する

［１１２０］任意の所与の時刻に、メンバは、それまでに受信されたイベントを、各イベントを作成し、かつ／または定義した計算デバイスおよび／または分散データベース・インスタンスに関連する識別子と共に記憶することができる。各イベントは、最初のイベント（親ハッシュを有しない）を除いて、２つのより以前のイベントのハッシュと、新しいメンバ（それらに参加するように勧誘した既存メンバのイベントを表す、単一の親イベント・ハッシュを有する）ごとの最初のイベントとを含む。イベントのこの集合を表す図が、描かれ得る。この図は、メンバごとの垂直線と、そのメンバによって作成され、かつ／または定義されたイベントごとのその線上のドットとを示すことができる。イベント（より高いドット）がより以前のイベント（より低いドット）のハッシュを含むときには必ず、対角線が、２つのドットの間に描かれる。イベントは、そのイベントがそのイベントのハッシュを介して（直接にまたは介在するイベントを介してのいずれかで）他のイベントを参照できる場合に、別のイベントにリンクされると言われ得る。

［１１２１］たとえば、図３は、ハッシュグラフ６００の例を示す。イベント６０２は、キャロルとの同期化の結果として、その同期化の後にボブによって作成され、かつ／または定義される。イベント６０２は、イベント６０４（ボブによって作成され、かつ／または定義された以前のイベント）のハッシュと、イベント６０６（キャロルによって作成され、かつ／または定義された以前のイベント）のハッシュとを含む。いくつかの実施形態では、たとえば、イベント６０２内に含まれるイベント６０４のハッシュは、その直接の先祖イベントであるイベント６０８および６１０へのポインタを含む。したがって、ボブは、イベント６０８および６１０を参照するのにイベント６０２を使用し、以前のイベントへのポインタを使用してハッシュグラフを再構成することができる。いくつかの例では、イベント６０２が、より以前の先祖イベントを介してハッシュグラフ６００内のイベントのそれぞれを参照できるので、イベント６０２は、ハッシュグラフ６００内の他のイベントにリンクされると言われ得る。たとえば、イベント６０２は、イベント６０４を介してイベント６０８にリンクされる。別の例として、イベント６０２は、イベント６０６およびイベント６１２を介してイベント６１６にリンクされる。

［１１２２］例のシステム２イベントが、記録されるトランザクションの「ペイロード」または他の情報をも含む、例のシステム１からのシステム。そのようなペイロードは、計算デバイスの直前のイベント以降に発生しかつ／または定義されたすべてのトランザクションおよび／または情報を用いてイベントを更新するのに使用され得る。たとえば、イベント６０２は、イベント６０４が作成され、かつ／または定義された時以降にボブによって実行されたすべてのトランザクションを含むことができる。したがって、イベント６０２を他の計算デバイスと同期化するときに、ボブは、この情報を共有することができる。したがって、ボブによって実行されたトランザクションは、イベントに関連付けられ、イベントを使用して他のメンバと共有され得る。

［１１２３］例のシステム３イベントが、デバッギング、診断、および／または他の目的に有用な現在時刻および／または現在日付をも含む、例のシステム１からのシステム。時刻および／または日付は、計算デバイス（たとえば、ボブ）がイベントを作成し、かつ／または定義する時のローカル時刻および／またはローカル日付とすることができる。そのような実施形態では、そのようなローカル時刻および／またはローカル日付は、残りのデバイスと同期化されない。他の実施形態では、時刻および／または日付は、デバイスにまたがって同期化され得る（たとえば、イベントを交換するときに）。さらなる他の実施形態では、グローバル・タイマが、時刻および／または日付を判定するのに使用され得る。

［１１２４］例のシステム４アリスが、ボブによって作成され、かつ／または定義されたボブ・イベントおよびそのようなイベントの先祖イベントを送らない、例のシステム１からのシステム。イベントｘは、ｙがｘのハッシュを含むか、ｙがｘの先祖であるイベントのハッシュを含む場合に、イベントｙの先祖である。同様に言えば、そのような実施形態では、ボブは、まだアリスによって記憶されていないイベントをアリスに送り、アリスによって既に記憶されているイベントは送らない。

［１１２５］たとえば、図４は、イベント６２２（黒い円）の先祖イベント（ドット付きの円）および子孫イベント（縞付きの円）を示す例のハッシュグラフ６２０を示す。線は、イベントに関する半順序を確立し、先祖は、黒いイベントの前になり、子孫は、黒いイベントの後になる。半順序は、白いイベントが黒いイベントの前後のどちらであるのかを示さず、したがって、全順序が、それらのシーケンスを決定するのに使用される。別の例として、図５は、１つの特定のイベント（塗り潰された円）と、各メンバがそのイベントの表示を受信する最初の時刻（縞付きの円）とを示す例のハッシュグラフを示す。キャロルが、イベント６２４を作成し、かつ／または定義するためにデイブと同期化するときに、キャロルが既にイベント６２２の先祖イベントを知っており、受信し終えているので、デイブは、そのようなイベントをキャロルに送らない。その代わりに、デイブは、キャロルがまだ受信しておらず、かつ／またはキャロルの分散データベース・インスタンス内に記憶していないイベントをキャロルに送る。いくつかの実施形態では、デイブは、キャロルが以前に受信したイベントに関してデイブのハッシュグラフが明らかにするものに基づいて、どのイベントをキャロルに送るべきかを識別することができる。イベント６２２は、イベント６２６の先祖である。したがって、イベント６２６のときに、デイブは、既にイベント６２２を受信している。図４は、デイブが、キャロルからイベント６２２を受信したボブからイベント６２２を受信したエドからイベント６２２を受信したことを示す。さらに、イベント６２４のときに、イベント６２２は、デイブが受信済みである、キャロルによって作成され、かつ／または定義された最後のイベントである。したがって、デイブは、デイブが記憶した、イベント６２２およびその先祖以外のイベントをキャロルに送ることができる。さらに、デイブからイベント６２６を受信する際に、キャロルは、キャロルの分散データベース・インスタンス内に記憶されたイベント内のポインタに基づいて、ハッシュグラフを再構成することができる。他の実施形態では、デイブは、キャロルがイベント６２２をデイブに送ること（図４には図示せず）と、デイブが、キャロルが既に受信済みであるイベントを識別するためにイベント６２２（およびその中の参照）を使用して識別することとに基づいて、キャロルに送るべきイベントを識別することができる。

［１１２６］例のシステム５受信側がイベントの先祖を受信し、かつ／または記憶し終えた後になるまでイベントが送られなくなるような順序で、両方のメンバが、他方にイベントを送る、例のシステム１からのシステム。したがって、送る側は、最も古いものから最も新しいものへとイベントを送り、受信側が、既に受信された２つの先祖イベントと２つのハッシュを比較することによって、イベントが受信されるときに各イベントに関する２つのハッシュをチェックできるようになる。送る側は、送る側のハッシュグラフ（たとえば、送る側によって定義されるデータベース状態変数）と、受信側が既に何を受信したことをそのハッシュグラフが示すのかとに基づいて、受信側に送るべきイベントを識別することができる。図３を参照すると、たとえば、ボブがイベント６０２を定義するためにキャロルと同期化しているときに、キャロルは、イベント６１９が、キャロルが受信した、ボブによって作成され、かつ／または定義された最後のイベントであることを識別することができる。したがって、キャロルは、ボブがそのイベントおよびその先祖について知っていると判定することができる。したがって、キャロルは、まずイベント６１８およびイベント６１６（すなわち、キャロルが受信済みである、ボブがまだ受信していない最も古いイベント）をボブに送ることができる。その後、キャロルは、イベント６１２を、およびその後にイベント６０６をボブに送ることができる。これは、ボブが、イベントを簡単にリンクし、ボブのハッシュグラフを再構成することを可能にする。キャロルのハッシュグラフを使用して、ボブがまだ受信していないイベントを識別することは、ボブがキャロルにイベントを要求しないので、同期化の効率を高めることができ、ネットワーク・トラフィックを減らすことができる。

［１１２７］他の実施形態では、最も最近のイベントが最初に送られ得る。受信側が（最も最近のイベント内の２つの以前のイベントのハッシュおよび／または最も最近のイベント内の以前のイベントへのポインタに基づいて）、それらが２つの以前のイベントのうちの１つをまだ受信していないと判定する場合に、受信側は、送る側に、そのようなイベントを送るように要求することができる。これは、受信側が、最も最近のイベントの先祖を受信し、かつ／または記憶し終えるまで発生し得る。図３を参照すると、そのような実施形態では、たとえば、ボブがキャロルからイベント６０６を受信するときに、ボブは、イベント６０６内のイベント６１２およびイベント６１４のハッシュを識別することができる。ボブは、アリスがイベント６０４を作成し、かつ／または定義するときに、イベント６１４がアリスから以前に受信されたと判定することができる。したがって、ボブは、キャロルにイベント６１４を要求する必要がない。ボブは、イベント６１２がまだ受信されていないと判定することもできる。その後、ボブは、キャロルにイベント６１２を要求することができる。その後、ボブは、イベント６１２内のハッシュに基づいて、ボブがイベント６１６または６１８を受信していないと判定し、したがって、これらのイベントをキャロルに要求することができる。その後、イベント６１６および６１８に基づいて、ボブは、彼がイベント６０６の先祖を受信したと判定することができる。

［１１２８］例のシステム６メンバが次に送るべき複数のイベントの間で選択を有するときに、イベントが、そのメンバによってこれまでに作成され、かつ／または定義された送られるバイトの総数を最小化するように選択されるという追加の制約を有する、例のシステム５からのシステム。たとえば、アリスが、ボブに送られるべき残された２つのイベントだけを有し、一方が１００バイトであり、キャロルによって作成されかつ／または定義され、一方が１０バイトであり、デイブによって作成されかつ／または定義され、これまでに、この同期化でアリスがキャロルによるイベントの２００バイトおよびデイブによる２１０バイトを既に送った場合に、アリスは、まずデイブにイベントを送らなければならず、その後にキャロルにイベントを送らなければならない。というのは、２１０＋１０＜１００＋２００であるからである。これは、単一のメンバが単一の巨大なイベントまたは小さいイベントの洪水のいずれかを送出する攻撃に対処するのに使用され得る。トラフィックが、ほとんどのメンバのバイト限界を超える（例のシステム７に関して議論されるように）場合には、例のシステム６の方法は、合法的なユーザのイベントではなく攻撃者のイベントが無視されることを保証することができる。同様に言えば、攻撃は、より大きいイベントの前により小さいイベントを送る（接続を縛り上げる１つの巨大なイベントに対して防御するために）ことによって減らされ得る。さらに、メンバが、単一の同期化内でイベントのそれぞれを送ることができない（たとえば、ネットワーク制限、メンバのバイト制限などの故に）場合には、そのメンバは、攻撃者によって定義されかつ／または作成されたイベントを単に送り、他のメンバによって作成されかつ／または定義された（少数の）イベントを全く送らないのではなく、各メンバからの少数のイベントを送ることができる。

［１１２９］例のシステム７ボブが、彼がこの同期化中に受信したいバイトの最大個数を示す数をアリスに送り、アリスが彼女の限度を応答する追加の第１ステップを有する例のシステム１からのシステム。その後、アリスは、次のイベントがこの限度を超えるときに送出を停止する。ボブは同じことを行う。そのような実施形態では、これが、転送されるバイト数を制限する。これは、収束するための時間を増やす可能性があるが、１同期化あたりのネットワーク・トラフィックの量を減らす。

［１１３０］例のシステム８以下のステップが同期化プロセスの初めに追加される、例のシステム１からのシステム。

［１１３１］ −アリスが、ボブによって作成されかつ／もしくは定義されたイベントまたはボブによって作成されかつ／もしくは定義されたイベントの先祖であるイベントを除く、彼女が受信しかつ／または記憶したイベントの集合Ｓを識別する。

［１１３２］ −アリスが、Ｓに含まれる各イベントを作成し、かつ／または定義したメンバを識別し、メンバのＩＤ番号のリストをボブに送る。アリスは、彼女が既に受信し、かつ／または記憶している、各メンバによって作成されかつ／または定義された複数のイベントをも送る。

［１１３３］ −ボブが、他のメンバによって作成され、かつ／または定義された、彼が受信したイベントの個数のリストを応答する。

［１１３４］ −その後、アリスは、ボブがまだ受信していないイベントだけをボブに送る。たとえば、アリスが、彼女がキャロルによって作成され、かつ／または定義された１００個のイベントを受信したことをボブに示し、ボブが、彼がキャロルによって作成され、かつ／または定義された９５個のイベントを受信したことを応答する場合に、アリスは、キャロルによって作成され、かつ／または定義された最も最近の５個のイベントだけを送る。

［１１３５］例のシステム９詐欺師を識別し、かつ／または処理するための追加機構を有する、例のシステム１からのシステム。各イベントは、そのメンバによって作成され、かつ／または定義された最後のイベントからのハッシュ（「自己ハッシュ」）と、別のメンバによって作成され、かつ／または定義された最後のイベントからのハッシュ（「外来ハッシュ（ｆｏｒｅｉｇｎｈａｓｈ）」）という２つのハッシュを含む。あるメンバが、同一の自己ハッシュを有する２つの異なるイベントを作成し、かつ／または定義する場合に、そのメンバは「詐欺師」である。アリスが、デイブによって作成され、かつ／または定義された、同一の自己ハッシュを有する２つの異なるイベントを受信することによって、デイブが詐欺師であることを発見する場合に、彼女は、彼が詐欺師であることのインジケータを記憶し、将来の彼との同期化を控える。彼女が、彼が詐欺師であることを発見し、それでももう一度彼と同期化し、その事実を記録する新しいイベントを作成し、かつ／または定義する場合には、アリスも詐欺師になり、アリスがさらにデイブと同期化することを知った他のメンバは、アリスとの同期化を停止する。いくつかの実施形態では、これは、一方向の同期化だけに影響する。たとえば、アリスが、識別子のリストと、彼女が受信したイベントの、メンバごとの個数とを送るときに、彼女は、詐欺師のＩＤまたはカウントを送らず、したがって、ボブは、対応する個数を応答しない。その後、アリスは、彼女が受信し、それに関してボブがそのようなイベントを受信したことの表示を受信していない詐欺師のイベントをボブに送る。その同期化が終了した後に、ボブも、デイブが詐欺師であると判定することができ（彼がまだデイブが詐欺師であると識別していない場合に）、ボブも、詐欺師との同期化を拒絶する。

［１１３６］例のシステム１０アリスが、彼女が識別し、そのイベントを彼女がまだ記憶している詐欺師のリストをボブに送ることによって同期化プロセスを開始し、ボブが、アリスが識別した詐欺師に加えて、彼が識別したすべての詐欺師を応答することを追加した、例のシステム９からのシステム。その後、彼らは通常通りに継続するが、お互いと同期化するときに、詐欺師のカウントを与えない。

［１１３７］例のシステム１１同期化中に受信されるすべての新しいイベントの内部のトランザクションに基づいて現在の状態（たとえば、システムのメンバによって定義されるデータベース状態変数によって取り込まれる）を繰り返して更新するプロセスを有する、例のシステム１内のシステム。これは、イベントのシーケンスが変化するときに必ず、より以前の状態のコピーに戻ることと、新しい順序でイベントを処理することによって現在の状態を再計算することとによって、その状態（たとえば、イベントの順序）を繰り返して再構築する第２のプロセスを含むこともできる。したがって、たとえば、各計算デバイスは、状態の２つのバージョンを維持することができる（新しいイベントおよびトランザクションが受信されるときに更新されるバージョンと、同意に達した後に限って更新されるバージョンと）。ある点で（たとえば、ある時間期間の後、所与の個数のイベントが定義され、かつ／または受信された後など）、新しいイベントおよびトランザクションが受信されるときに更新される状態のバージョンは、破棄され得、同意に達した後に限って更新される状態の新しいコピーが、新しいイベントおよびトランザクションが受信されるときに更新される状態の新しいバージョンとして作られ得る。これは、両方の状態の同期化を保証することができる。

［１１３８］いくつかの実施形態では、現在の状態は、トランザクションの結果に関連する状態、差引勘定、条件、および／または類似物である。同様に言えば、状態は、トランザクションによって変更されるデータ構造および／または変数を含むことができる。たとえば、トランザクションが、銀行口座の間の送金である場合に、現在の状態は、口座の現在の差引勘定とすることができる。別の例として、トランザクションが、マルチプレイヤ・ゲームに関連する場合に、現在の状態は、ゲームに関連する、位置、ライフ数、入手したアイテム、ゲームの状態、および／または類似物とすることができる。

［１１３９］例のシステム１２状態（たとえば、銀行口座差引勘定、ゲーム状態など）を維持するための「高速クローン」ａｒｒａｙＬｉｓｔの使用によって高速化された、例のシステム１１内のシステム。高速クローンａｒｒａｙＬｉｓｔは、１つの追加の特徴すなわち、オリジナルのコピーである新しいオブジェクトを作成し、かつ／または定義するように見える「クローン」動作をサポートする、配列のように働くデータ構造である。クローンは、クローンに対する変更がオリジナルには影響しないので、真のコピーであるかのように働く。しかし、クローニング動作は、真のコピーの作成より高速である。というのは、クローンの作成が、あるａｒｒａｙＬｉｓｔの内容全体を別のａｒｒａｙＬｉｓｔにコピーすることおよび／または更新することを実際には伴わないからである。オリジナル・リストの２つのクローンおよび／またはコピーを有するのではなく、それぞれがハッシュ・テーブルおよびオリジナル・リストへのポインタを有する２つの小さいオブジェクトが、使用され得る。書込が、クローンに対して行われるときに、ハッシュ・テーブルは、どの要素が変更されるのかと新しい値とを記憶する。読取が、ある位置に対して実行されるときには、まずハッシュ・テーブルがチェックされ、その要素が変更されている場合には、ハッシュ・テーブルからの新しい値が返される。そうでない場合には、オリジナルのａｒｒａｙＬｉｓｔからのその要素が返される。この形で、２つの「クローン」は、当初には、オリジナルのａｒｒａｙＬｉｓｔへのポインタにすぎない。しかし、それぞれが繰り返して変更されるときに、それぞれは、それ自体とオリジナルのリストとの間の差を記憶する大きいハッシュ・テーブルを有するように成長する。クローンは、それ自体がクローニングされ、データ構造を、それぞれがそれ自体のハッシュ・テーブルとその親へのポインタとを有するオブジェクトのツリーに拡大させることができる。したがって、読取は、要求されたデータを有する頂点が見つかるか、ルートに達するまで、木を登るウォークを引き起こす。頂点が大きすぎるか複雑すぎるようになる場合には、頂点を、親の真のコピーに置換することができ、ハッシュ・テーブル内の変更は、コピーに対して行われ得、ハッシュ・テーブルは破棄され得る。さらに、クローンがもはや不要になった場合には、ガーベジ・コレクション中に、クローンは、木から除去され得、木は、縮小され得る。

［１１４０］例のシステム１３状態（たとえば、銀行口座差引勘定、ゲーム状態など）を維持するための「高速クローン」ハッシュ・テーブルの使用によって高速化された、例のシステム１１内のシステム。これは、木のルートがａｒｒａｙＬｉｓｔではなくハッシュ・テーブルであることを除いて、システム１２と同一である。

［１１４１］例のシステム１４状態（たとえば、銀行口座差引勘定、ゲーム状態など）を維持するための「高速クローン」リレーショナル・データベースの使用によって高速化された、例のシステム１１内のシステム。たとえば、高速クローン・データベースは、例のシステム１１に関して議論したように、状態の２つのコピーを維持するのに使用され得る。これは、既存のリレーショナル・データベース管理システム（ＲＤＢＭＳ）の周囲のラッパーとして働くオブジェクトである。各見掛けの「クローン」は、実際にはＩＤ番号およびデータベースを含むオブジェクトへのポインタを有するオブジェクトである。ユーザのコードが、データベースに対して構造化照会言語（ＳＱＬ）照会を実行することを試みるときに、その照会は、まず変更され、その後に実際のデータベースに送られる。実際のデータベースは、各テーブルがクローンＩＤのための１つの追加フィールドを有することを除いて、クライアント・コードによって見られるデータベースと同一である。たとえば、クローンＩＤ１を有するオリジナル・データベースがあり、ＩＤ２および３を有するそのデータベースの２つのクローンが作られる（たとえば、状態の２つのコピーを維持するのに使用される）と仮定する。各テーブル内の各行は、クローンＩＤフィールド内に１、２、または３を有する。照会が、ユーザ・コードからクローン２に来るときに、照会は、照会がそのフィールド内に２または１を有する行からのみ読み取るようにするために変更される。同様に、３への読取は、３または１のＩＤを有する行を調べる。構造化照会言語（ＳＱＬ）コマンドが、クローン２に行き、ある行を削除するように告げ、その行が１を有する場合には、そのコマンドは、１を３に変更しなければならず、これは、その行を、もはやクローン２および３によって共有されず、今や、３のみに可視であるものとしてマークする。動作中に複数のクローンがある場合には、その行の複数のコピーが挿入され得、それぞれが、異なるクローンのＩＤに変更され得、その結果、新しい行は、その行を「削除」したクローン以外のクローンに可視になる。同様に、ある行が、クローン２に追加される場合に、その行は、２のＩＤを有するテーブルに追加される。行の変更は、削除およびその後の挿入と同等である。前と同様に、複数のクローンがガーベジ・コレクションされる場合には、木は、単純化され得る。その木の構造は、クローンからアクセス可能ではなく、純粋に内部的に使用される追加テーブル内に記憶される。

［１１４２］例のシステム１５状態を維持するための「高速クローン」ファイル・システムの使用によって高速化された、例のシステム１１内のシステム。これは、ファイル・システムの周囲のラッパーとして働くオブジェクトである。ファイル・システムは、ファイル・システムの異なるバージョンを管理するために高速クローン・リレーショナル・データベースを使用して、既存のファイル・システムの上に構築される。基礎になるファイル・システムは、１つのディレクトリ内にまたはファイル名に従って分割されて（ディレクトリを小さく保つために）のいずれかで、多数のファイルを記憶する。ディレクトリ・ツリーは、データベース内に記憶され得、ホスト・ファイル・システムには提供されない。ファイルまたはディレクトリがクローニングされるときには、「クローン」は、ＩＤ番号を有するオブジェクトにすぎず、データベースは、このクローンが現在存在することを反映するように変更される。高速クローン・ファイル・システムがクローニングされる場合に、それは、ユーザにとって、新しいハード・ドライブ全体が作成され、かつ／または定義され、既存のハード・ドライブのコピーを用いて初期化されるかのように見える。一方のコピーに対する変更は、他方のコピーに対して影響を有することができない。実際には、各ファイルまたはディレクトリの１つのコピーだけがあり、あるクローンを介してファイルが変更されるときに、コピーが行われる。

［１１４３］例のシステム１６高速クローン・ファイル・システム内のファイルのＮバイト部分ごとにホスト・オペレーティング・システム上で別々のファイルが作成され、かつ／または定義される、例のシステム１５内のシステム。Ｎは、たとえば４０９６または１０２４など、なんらかの適当なサイズとすることができる。この形で、１バイトが大きいファイル内で変更される場合に、大きいファイルの１つのチャンクだけが、コピーされ、変更される。これは、数バイトだけが異なる多数のファイルをドライブ上に記憶する時の効率をも高める。

［１１４４］例のシステム１７各メンバが、それが作成し、かつ／または定義するイベントの一部またはすべてに、ある以前の時刻までに発生したイベントの個数と一緒に、その点での状態のハッシュを含め、現在はイベントの順序に関する同意があることをそのメンバが認識し、かつ／または識別することを示す、例のシステム１１内のシステム。あるメンバが、所与の状態に関するユーザの過半数からのそのようなハッシュを含む署名付きイベントを収集した後に、そのメンバは、その点での同意状態の証拠としてそれを記憶し、その点の前のイベントおよびトランザクションをメモリから削除することができる。

［１１４５］例のシステム１８中央値または過半数を計算する動作が、重み付きの中央値または重み付きの過半数に置換され、メンバは、その「ステーク」によって重みを付けられる、例のシステム１内のシステム。ステークは、そのメンバの票が何票になるのかを示す数である。ステークは、暗号通貨の持ち分、またはメンバが参加するように初めて勧誘されたときに割り当てられ、その後、メンバが参加するように勧誘する新しいメンバの間で分割される任意の数とすることができる。古いイベントは、十分なメンバが同意状態に合意し終え、その結果、彼らの総ステークが、存在するステークの過半数になるときに、破棄され得る。全順序が、メンバによって貢献されるランクの中央値を使用して計算される場合に、その結果は、半分のメンバがそれより高いランクを有し、半分のメンバがそれより低いランクを有する数である。その一方で、全順序が、重み付き中央値を使用して計算される場合には、その結果は、総ステークの約半分がそれより低いランクに関連し、総ステークの約半分がそれより高いランクに関連する数である。重み付きの投票および中央値は、あるメンバが、膨大な数の「靴下パペット」ユーザに参加するように勧誘し、これらのユーザのそれぞれが、単純に勧誘するメンバによって制御された偽名である、シビル攻撃を防ぐのに有用である可能性がある。勧誘するメンバが、勧誘に伴って彼らのステークを分割することを強制される場合に、靴下パペットは、同意結果を制御する試みにおいて攻撃者にとって有用ではなくなる。したがって、プルーフオブステークは、いくつかの状況で有用である可能性がある。

［１１４６］例のシステム１９単一の分散データベースではなく、階層内に複数のデータベースがある、例のシステム１内のシステム。たとえば、ユーザがそのメンバである単一のデータベースがあり、その後、複数のより小さいデータベースまたは「チャンク」があり、そのそれぞれがメンバの部分集合を有する場合がある。チャンク内でイベントが発生するときには、それらのイベントは、そのチャンクのメンバの間で同期化され、そのチャンクの外部のメンバの間では同期化されない。その後、時々、同意順序がチャンク内で決定された後に、結果の状態（または同意全順序を有するイベント）は、大きいデータベースのメンバシップ全体と共有され得る。

［１１４７］例のシステム２０状態（たとえば、システムのメンバによって定義されたデータベース状態変数によって取り込まれる）を更新するソフトウェアを更新するイベントを有する能力を有する、例のシステム１１内のシステム。たとえば、イベントＸおよびＹが、これらのイベント内のトランザクションを読み取り、その後に適当に状態を変更するソフトウェア・コードに従って状態を変更するトランザクションを含むことができる。その後、イベントＺは、ソフトウェアの新しいバージョンが現在入手可能であることの通知を含むことができる。全順序が、イベントが順序Ｘ、Ｚ、Ｙで発生すると告げる場合に、状態は、古いソフトウェアを用いてＸ内のトランザクションを処理し、その後、新しいソフトウェアを用いてＹ内のトランザクションを処理することによって更新され得る。しかし、同意順序がＸ、Ｙ、Ｚである場合には、ＸとＹとの両方が、古いソフトウェアを用いて更新され得、これは、異なる最終的な状態を与えることができる。したがって、そのような実施形態では、コードを更新するための通知が、イベント内で発生することができ、その結果、コミュニティ（たとえば、分散データベース内のメンバ）は、いつ古いバージョンから新しいバージョンに切り替えるべきかに関する同意を達成できるようになる。これは、メンバが同期化された状態を維持することを保証する。これは、システムが、再ブートしまたはプロセスを再開始する必要なしに、アップグレード中であっても走行したままになれることをも保証する。

［１１４８］上で説明したシステムは、最終的な同意と共に分散同意のための効率的な収束機構を作成し、かつ／または達成すると期待される。複数の定理が、以下で示すようにこれに関して証明され得る。

［１１４９］例の定理１イベントｘが、半順序でイベントｙに先行する場合に、所与のメンバの、所与の時刻の他のメンバの知識において、他のメンバのそれぞれは、ｙの前にｘの表示を受信するか、ｙの表示をまだ受信していないかのいずれかである。

［１１５０］証明イベントｘが半順序でイベントｙに先行する場合に、ｘは、ｙの先祖である。あるメンバが、初めてｙの表示を受信するときに、そのメンバは、より以前にｘの表示を既に受信している（その場合に、彼らは、ｙの前にｘについて聞いている）か、同期化がｘとｙとの両方をそのメンバに提供するケースである（その場合に、彼らは、その同期化中にｙの前にｘについて聞く。というのは、単一の同期化中に受信されるイベントが、例のシステム５に関して説明したように、先祖関係と一貫する順序で受信されたと考えられるからである）かのいずれかである。証明終り。

［１１５１］例の定理２任意の所与のハッシュグラフに関して、ｘが半順序でｙに先行する場合に、ｘは、そのハッシュグラフに関して計算される全順序でｙに先行する。

［１１５２］証明ｘが半順序でｙに先行する場合に、定理１によって

［１１５３］すべてのｉについて、ｒａｎｋ（ｉ，ｘ）＜ｒａｎｋ（ｉ，ｙ）である。

［１１５４］ここで、ｒａｎｋ（ｉ，ｘ）は、メンバｉによってイベントｘに割り当てられるランクであり、ｘがメンバｉによって受信される最初のイベントである場合には１、２番目である場合には２、以下同様である。ｍｅｄ（ｘ）が、すべてのｉにわたるｒａｎｋ（ｉ，ｘ）の中央値であり、ｍｅｄ（ｙ）も同様であるものとする。

［１１５５］所与のｋについて、ｒａｎｋ（ｉ１，ｘ）が、小さい方からｋ番目のｘランクになり、ｒａｎｋ（ｉ２，ｙ）が、小さい方からｋ番目のｙランクになるようにｉ１およびｉ２を選択する。すると、

［１１５６］ｒａｎｋ（ｉ１，ｘ）＜ｒａｎｋ（ｉ２，ｙ）である。

［１１５７］これは、ｒａｎｋ（ｉ２，ｙ）が、ｙランクのｋ以上であり、ｙランクのそれぞれが、対応するｘランクより厳密に大きいからである。したがって、ｒａｎｋ（ｉ２，ｙ）は、ｘランクの少なくともｋより厳密に大きく、したがって、小さい方からｋ番目のｘランクより厳密に大きい。この議論は、すべてのｋにあてはまる。

［１１５８］ｎが、メンバの数（ｉ値の個数である）であるものとする。ｎは、奇数または偶数のいずれかでなければならない。ｎが奇数である場合には、ｋ＝（ｎ＋１）／２であり、小さい方からｋ番目のランクが中央値になるものとする。したがって、ｍｅｄ（ｘ）＜ｍｅｄ（ｙ）である。ｎが偶数である場合には、ｋ＝ｎ／２のときに、小さい方からｋ番目のｘランクは、小さい方からｋ番目のｙランクより厳密に小さく、小さい方から（ｋ＋１）番目のｘランクは、小さい方から（ｋ＋１）番目のｙランクより厳密に小さい。したがって、この２つのｘランクの平均値は、２つのｙランクの平均値より小さい。したがって、ｍｅｄ（ｘ）＜ｍｅｄ（ｙ）である。したがって、両方のケースで、ｘランクの中央値は、ｙランクの中央値より厳密に小さい。したがって、全順序が、中央値ランクによってアクションをソートすることによって定義される場合に、ｘは、全順序でｙに先行する。証明終り。

［１１５９］例の定理３「ゴシップ期間」が、既存のイベントが同期化を介して全メンバに伝搬するための時間の長さである場合には、

［１１６０］１ゴシップ期間の後全メンバがイベントを受信し終える

［１１６１］２ゴシップ期間の後全メンバがこれらのイベントの順序に合意する

［１１６２］３ゴシップ期間の後全メンバが、合意に達したことを知る

［１１６３］４ゴシップ期間の後全メンバが、他の全メンバからデジタル署名を入手し、この同意順序に裏書する。

［１１６４］証明Ｓ０が、所与の時刻Ｔ０までに作成され、かつ／または定義されたイベントの集合であるものとする。すべてのメンバが、何度でも、すべての他のメンバと最終的に同期化する場合に、１の確率で、Ｓ０内のイベントがすべてのメンバに行き渡り終え、その結果、すべてのメンバがすべてのイベントを知っている時刻Ｔ１が最終的に存在する。それは、第１のゴシップ期間の終りである。Ｓ１が、時刻Ｔ１に存在し、Ｔ０にはまだ存在しなかったイベントの集合であるものとする。１の確率で、すべてのメンバが、時刻Ｔ１に存在したイベントである集合Ｓ１内のすべてのイベントを受信し終える時刻Ｔ２が最終的に存在する。それは、第２のゴシップ期間の終りである。同様に、Ｔ３は、Ｔ２までに存在するがＴ１の前には存在しない、Ｓ２内のすべてのイベントが、全メンバに行き渡り終える時である。各ゴシップ期間が、最終的に１の確率で終了することに留意されたい。平均して、それぞれは、ｎ個のメンバがある場合に、ｌｏｇ２（ｎ）回の同期化を実行するのに要する時間程度に存続する。

［１１６５］時刻Ｔ１までに、すべてのメンバは、Ｓ０内のすべてのイベントを受信済みになる。

［１１６６］時刻Ｔ２までに、所与のメンバ、アリスは、Ｓ０内のすべてのイベントを受信する他のメンバのそれぞれのレコードを受信済みになる。したがって、アリスは、すべてのメンバのＳ０内のすべてのアクションのランク（そのメンバがそのアクションを受信した順序である）を計算し、その後、ランクの中央値によってイベントをソートすることができる。結果の全順序は、Ｓ０内のイベントに関して変化しない。これは、結果の順序が、各メンバがこれらのイベントのそれぞれの表示を初めて受信した順序（変化しない）の関数であるからである。アリスの計算された順序が、Ｓ０イベントの間に散在するＳ１からのいくつかのイベントを有することが可能である。それらのＳ１イベントは、Ｓ０イベントのシーケンス内に含まれる場合に、それでも変化する可能性がある。しかし、Ｓ０内のイベントの相対順序は変化しない。

［１１６７］時刻Ｔ３までに、アリスは、Ｓ０およびＳ１の和集合の全順序を学習し終え、その和集合内のイベントの相対順序は、変化しなくなる。さらに、彼女は、このシーケンス内で、Ｓ１からの最も早期のイベントを発見することができ、Ｓ１の前のイベントのシーケンスが、Ｓ０の外部の新しいイベントの挿入によってさえ変化しないと結論することができる。したがって、時刻Ｔ３までに、アリスは、最初のＳ１イベントの前のヒストリ内のイベントの順序に関して同意に達したと判定することができる。彼女は、これらのイベントがこの順序で発生することから生じる状態（たとえば、アリスによって定義されたデータベース状態変数によって取り込まれる）のハッシュにデジタル証明し、彼女が作成し、かつ／または定義する次のイベントの一部としてその署名を送出することができる。

［１１６８］時刻Ｔ４までに、アリスは、他のメンバから同様の署名を受信し終える。その点で、彼女は、署名が立証する状態と一緒に署名のリストを単純に保持することができ、彼女は、最初のＳ１イベントの前に記憶したイベントを破棄することができる。証明終り。

［１１６９］本明細書で説明されるシステムは、素早く安全に同意に達する分散データベースを説明するものである。これは、多数の応用例に関する有用な基本構成ブロックとすることができる。たとえば、トランザクションが、ある暗号通貨財布から別の暗号通貨財布への暗号通貨の振替を記述し、状態が、単純に各財布内の通貨額の言明である場合に、このシステムは、既存システム内の高コストのプルーフオブワークを回避する暗号通貨システムを構成する。自動的なルールの実施は、これが、現在の暗号通貨で一般的ではない特徴を追加することを可能にする。たとえば、失われた硬貨は、デフレーションを回避するために、財布がある時間期間の間に暗号通貨を送らず、受信しない場合に、その財布が削除され、その価値が、他の既存の財布が現在含む額に比例して他の既存の財布に分配されるというルールを実施することによって、回復され得る。その形で、貨幣供給は、財布の秘密鍵が失われる場合であっても、増加も減少もしない。

［１１７０］別の例は、サーバ上でプレイされる多人数同時参加型オンライン（ＭＭＯ）ゲームのように働くが、中央サーバを使用せずにそれを達成する、分散ゲームである。同意は、中央サーバが主導権を握ることなく達成され得る。

［１１７１］別の例は、そのようなデータベースの上に構築されるソーシャル・メディア用のシステムである。トランザクションがデジタル署名され、メンバが、他のメンバに関する情報を受信するので、これは、現在のシステムを超えるセキュリティおよび便宜の利点を提供する。たとえば、強力なアンチスパム・ポリシを有する電子メール・システムが実施され得る。というのは、電子メールが、捏造された返信用アドレスを有することができないからである。そのようなシステムは、単一の分散データベース内で、電子メール、ツイート、テキスト、フォーラム、ウィキ、および／または他のソーシャル・メディアによって現在行われている機能を組み合わせる、統一されたソーシャルシステムになることもできる。

［１１７２］別の例は、警察、消防、医療、軍、国家警備隊、および／または米連邦緊急事態管理局（ＦＥＭＡ）などの様々な機関を調整するための、災害対応で使用される通信システムである。分散データベースは、各機関のメンバに状況に関する共通の見解を与えるのに使用され得、各機関は、情報を寄与し、他の機関からの情報へのアクセスを有する。それは、様々なメンバが同一の情報へのアクセスを有することと、事故または攻撃者が、ネットワークが意図された通りに動作するのを妨げることが困難であることとを保証する。中央サーバ上の単一のデータベースは、たとえば、インサイダまたはマルウェアに感染した単一のコンピュータによって破壊され得る。中央サーバ上のそのような単一のデータベースは、危険に晒されたコンピュータ（たとえば、世界中）から来るインターネット・パケットが殺到する分散サービス拒否（ＤＤｏＳ）攻撃によって強制的にオフラインにされる可能性もある。別の例として、中央サーバ上のそのような単一のデータベースは、通信ワイヤまたは衛星局が災害中に損傷を受けるのでオフラインになる可能性もある。しかし、分散データベースは、そのような問題に対して弾力的になることができる。さらに、分散データベースが、ルールを実施する分散コードを実行する場合に、メンバは、単一の危険に晒されたメンバが、システムを圧倒し、その中からシステムをシャットダウンするためにシステムに余分なデータを殺到させることができないことを協力して保証することができる。この例のユース・ケースは、プルーフオブワークに基づくブロックチェーンを使用して実施することが困難である。というのは、緊急応答機関が、そのような非効率的なシステムに必要な強力なコンピュータを走行させる可能性が低いからである。そのようなユース・ケースは、Ｐａｘｏｓまたはラウンドロビン・ブロックチェーンなどのリーダーに基づく同意システムを使用して実施される場合に、弾力的でもないはずである。というのは、ある時刻の単一のコンピュータに対するＤＤｏＳが、現在のリーダーを継続的にシャットダウンし、コミュニティが新しいリーダーに切り替えたときに新しいコンピュータへの攻撃に切り替えることができるからである。したがって、ブロックチェーンおよびリーダー・ベースの同意システムに関する問題を救済するために、弾力的な分散データベースが、本明細書で説明される分散データベース・システムなどの分散同意システムを使用して実施され得る。

［１１７３］同様に、本明細書で説明される分散データベース・システムは、軍事作戦に関する情報の柔軟な通信および共有される見解を実施するのに使用され得る。さらなる別の例では、本明細書で説明される分散データベース・システムは、モノのインターネット・オブジェクトを制御するのに使用される分散データベース、監視制御およびデータ取得（ｓｕｐｅｒｖｉｓｏｒｙｃｏｎｔｒｏｌａｎｄｄａｔａａｃｑｕｉｓｉｔｉｏｎ、ＳＣＡＤＡ）インフラストラクチャ、または「スマート・シティ」内のセンサおよびコントロールを実施するのに使用され得る。そのようなシステムは、上で説明した災害管理の例の実施態様に類似する特徴および／または要件を含む可能性がある。

［１１７４］他の応用例は、グループが全体として契約または文書に署名するために協力する、グループ・デジタル署名などのより洗練された暗号機能を含むことができる。これおよびマルチパーティ計算（ｍｕｌｔｉｐａｒｔｙｃｏｍｐｕｔａｔｉｏｎ）の他の形は、そのような分散同意システムを使用して有用に実施され得る。

［１１７５］別の例は、公開台帳（ｐｕｂｌｉｃｌｅｄｇｅｒ）システムである。誰もが、システム内に情報を記憶するために小額の暗号通貨（または実世界の通貨）毎バイト毎年を支払うことによって、システム内にある情報を記憶するために支払うことができる。その後、これらの基金は、そのデータを記憶するメンバと、同意を達成するために働くために繰り返して同期化するメンバとに自動的に分配され得る。それは、メンバに、彼らが同期化するたびに小額の暗号通貨を自動的に送金することができる。

［１１７６］別の例は、トラフィック分析に抵抗するセキュア・メッセージング・システムである。この例では、分散データベースは、メンバの間の暗号化されたメッセージを含み、かつ／または記憶することができる。各メンバは、すべてのメッセージへのアクセスを有するが、メッセージは暗号化されており、その結果、所期の受信側だけがメッセージを暗号化解除できるようになっている。コミュニティは、メンバがメッセージを送った時を知るが、そのメッセージが誰に送られたのかを知らない。各メンバは、すべてのメッセージの暗号化解除を試み、暗号化解除されたメッセージが有効であり、正しいチェックサムを有するという事実によって、彼らに送られたメッセージを認識する。

［１１７７］代替案では、そのようなシステムでの計算要件は、たとえば、以下の形で低減され得る。メンバの各対は、当初に、２つの共有される秘密鍵（対のメンバごとに１つ）をネゴシエートすることができ、この秘密鍵は、彼らが、２つの異なる暗号的に安全な乱数ジェネレータ（ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙｓｅｃｕｒｅｒａｎｄｏｍｎｕｍｂｅｒｇｅｎｅｒａｔｏｒ、ＣＳＰＲＮＧ）（対のメンバごとに１つ）に種を与えるのに使用する。アリスが、ボブと共にそのような鍵を作成した場合に、彼女は、ボブ宛のメッセージをデータベースに追加するたびに新しい擬似乱数を生成するのに彼女のＣＳＰＲＮＧを使用し、彼女は、その数を暗号化されたメッセージに添付する。その後、ボブは、各メッセージに添付された数が、彼宛のメッセージを示すかどうかを知るために、データベース内の各メッセージに添付された数を素早くチェックすることができる。ボブは、共有された鍵を知っているので、したがって、彼は、アリスが生成する数のシーケンスを知っており、したがって、彼は、アリスから彼にアドレッシングされたメッセージに関してメッセージをスキャンするときに探すべき番号を知っている。彼が、そのような番号が添付されたメッセージを見つけるときに、彼は、それらがアリスから彼へのメッセージであることを知り、それらを暗号化解除することができる。キャロルからデイブへなどの関連しないメッセージは、異なる番号を添付され、ボブは、それらを暗号化解除することなく破棄する。いくつかのインスタンス化では、アリスおよびボブは、彼らの共有鍵を周期的に再ネゴシエートし、古い鍵を消去する。これは、将来に、アリスおよびボブの鍵が最終的に危険に晒された場合であっても、第三者がアリスとボブとの間で送られたメッセージ識別をすることを困難にする、前方秘匿性（ｆｏｒｗａｒｄｓｅｃｕｒｉｔｙ）を提供する。

［１１７８］これらの例は、分散同意データベースが、多数の応用例の構成要素として有用であることを示す。データベースが、高コストのプルーフオブワークを使用せず、おそらくはより安価なプルーフオブステークをその代わりに使用するので、このデータベースは、すべてのノードがより小さいコンピュータまたはモバイル・デバイスおよび組込みデバイスでさえ走行する状態で走行することができる。

［１１７９］上では２つの以前のイベントのハッシュ（１つの自己ハッシュおよび１つの外来ハッシュ）を含むイベントとして説明されたが、他の実施形態では、メンバは、３つの以前のイベントのハッシュ（１つの自己ハッシュおよび２つの外来ハッシュ）を含むイベントを作成し、かつ／または定義するために他の２つのメンバと同期化することができる。さらなる他の実施形態では、任意の個数のメンバからの以前のイベントの任意の個数のイベント・ハッシュが、１つのイベント内に含まれ得る。いくつかの実施形態では、異なるイベントが、以前のイベントの異なる個数のハッシュを含むことができる。たとえば、第１のイベントが、２つのイベント・ハッシュを含むことができ、第２のイベントが、３つのイベント・ハッシュを含むことができる。

［１１８０］イベントは、上では以前のイベントのハッシュ（または暗号ハッシュ値）を含むものとして説明されるが、他の実施形態では、イベントは、ポインタ、識別子、および／または以前のイベントへの任意の他の適切な参照を含むように作成され、かつ／または定義され得る。たとえば、イベントは、以前のイベントに関連し、これを識別するのに使用され、したがってイベントをリンクする通し番号を含むように作成され、かつ／または定義され得る。いくつかの実施形態では、そのような通し番号は、たとえば、イベントを作成し、かつ／または定義したメンバに関連する識別子（たとえば、媒体アクセス制御（ＭＡＣ）アドレス、インターネット・プロトコル（ＩＰ）アドレス、割り当てられたアドレス、および／または類似物）およびそのメンバによって定義されたイベントの順序を含むことができる。たとえば、１０の識別子を有するメンバは、イベントがそのメンバによって作成されかつ／または定義された１５番目のイベントであると、そのイベントに１０１５の識別子を割り当てることができる。他の実施形態では、任意の他の適切なフォーマットが、識別子をイベントに割り当てるのに使用され得る。

［１１８１］他の実施形態では、イベントは、完全な暗号ハッシュを含むことができるが、これらのハッシュの一部だけが、同期化中に送信される。たとえば、アリスが、ハッシュＨを含むイベントをボブに送り、Ｊが、Ｈの最初の３バイトであり、アリスが、彼女が記憶したイベントおよびハッシュのうちで、Ｈが、Ｊから始まる唯一のハッシュであると判定する場合に、彼女は、同期化中にＨではなくＪを送ることができる。その後、ボブが、彼がＪから始まる別のハッシュを有すると判定する場合に、彼は、完全なＨを要求するためにアリスに応答することができる。その形で、ハッシュは、送信中に圧縮され得る。

［１１８２］］図１３は、一実施形態による、分散データベースの初期状態の表現である。いくつかの実施態様では、分散データベースは、創設者メンバ、この例ではアリス、ボブ、キャロル、デイブ、およびエドによって初期化され得る。各メンバは、メンバ鍵の対１３０５を定義する。メンバ鍵の各対は、あるメンバに関連する一意の秘密鍵および一意の公開鍵を含むことができる。たとえば、アリスはＡ＿Ｐｒｉｖａｔｅ＿ＫｅｙおよびＡ＿Ｐｕｂｌｉｃ＿Ｋｅｙを有し、ボブは、Ｂ＿Ｐｒｉｖａｔｅ＿ＫｅｙおよびＢ＿Ｐｕｂｌｉｃ＿Ｋｅｙを有し、列１３０５に示されているように、キャロル、デイブ、およびエドについても同様である。各公開鍵／秘密鍵対は、２つの一意に関係する暗号鍵（たとえば、大きい数）を含む。下記は、公開鍵の例である。

［１１８３］３０４８０２４１００Ｃ９１８ＦＡＣＦ８ＤＥＢ２ＤＥＦＤ５ＦＤ３７８９Ｂ９Ｅ０６９ＥＡ９７ＦＣ２０５Ｅ３５Ｆ５７７ＥＥ３１Ｃ４ＦＢＣ６Ｅ４４８１１７Ｄ８６ＢＣ８ＦＢＡＦＡ３６２Ｆ９２２ＢＦ０１Ｂ２Ｆ４０Ｃ７４４２６５４Ｃ０ＤＤ２８８１Ｄ６７３ＣＡ２Ｂ４００３Ｃ２６６Ｅ２ＣＤＣＢ０２０３０１０００１

［１１８４］公開鍵は、たとえば公にアクセス可能なリポジトリまたはディレクトリを介して、分散データベース内の他のメンバから使用可能にされる。しかし、秘密鍵は、それぞれの所有者に秘密のままになる。鍵対が数学的に関係付けられるので、公開鍵を用いて暗号化されたメッセージは、その秘密鍵相対物によってのみ暗号化解除され得、逆も同様である。たとえば、ボブが、アリスにメッセージを送ろうと思い、アリスだけがそのメッセージを読めることを保証したいと思う場合に、彼は、アリスの公開鍵を用いてメッセージを暗号化することができる。アリスだけが、彼女の秘密鍵へのアクセスを有し、その結果、暗号化されたデータをそのオリジナルの形に戻って暗号化解除する能力を有する唯一のメンバである。アリスだけが彼女の秘密鍵へのアクセスを有するので、アリスだけが、暗号化されたメッセージを暗号化解除することができることが可能である。他の誰かが暗号化されたメッセージへのアクセスを得る場合であっても、彼らはアリスの秘密鍵へのアクセスを有しないはずなので、そのメッセージは秘密のままになる。

［１１８５］いくつかの実施態様では、列１３０５内の対は、分散データベース一意識別子（ＤｉｓｔｒｉｂｕｔｅｄＤａｔａｂａｓｅＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ、Ｄ２ＩＤ）１３０９を計算するためのパラメータとして使用される。Ｄ２ＩＤ１３０９が、一般に、創設者メンバおよび公開鍵のそれぞれによって提供されるパラメータのランダムさを考慮すると複製が難しく、したがって、分散データベースに高いセキュリティ・レベルを有利に提供することを了解されたい。さらに、ランダムさを高めるために、各メンバの各鍵対は、そのメンバが参加する分散データベースごとに異なるものとすることができる。さらに、そのような鍵対は、各メンバによってランダムに生成され得る。したがって、同一のメンバが第２のデータベースを定義する場合であっても、第２の分散データベースのＤ２ＩＤは、第１の分散データベースのＤ２ＩＤとは異なる。

［１１８６］さらに、いくつかの例では、異なるナンス（たとえば、ランダムに生成される識別子）が、データベースのＤ２ＩＤを計算するときに各メンバ公開鍵と対にされ得る。ナンスは、各メンバによっておよび／または各メンバのためにランダムに生成され得る。これは、同一のメンバが同一の公開鍵を用いて第２のデータベースを定義する場合であっても、ナンスが異なり、したがって、第２の分散データベースのＤ２ＩＤが異なることを保証することによって、セキュリティを高めることができる。

［１１８７］いくつかの実施態様では、メンバシップ１３０３は、分散データベースの状態に関連する複数のメンバシップ・リストがその中に記録される、データ構造または他の論理的におよび／もしくは物理的に実施されるコンテナとして実施され得る。いくつかの例では、メンバシップ１３０３は、分散データベースの現在の状態に関連するメンバの属性を含む現在のメンバシップ・リスト（ＣＭＬ）１３０１を含む。ＣＭＬ１３０１は、分散データベースによって実行される動作、たとえば、図１４を参照して議論されるデータベースへのメンバの追加または除去の際に、変化するように構成される。分散データベースの初期状態では、ＣＭＬ１３０１は、分散データベースの創設メンバの属性、たとえばメンバシップ鍵対１３０５と、そのような創設メンバに関連する他の適切な属性とを含む。

［１１８８］いくつかの例では、ＣＭＬメンバおよびそれらに関連する属性は、経時的に、たとえば分散データベースへのメンバの追加および／または除去の際に、変化する。したがって、ＣＭＬメンバの第１の集合が、第１の時間期間中に分散データベースを実施することができ、ＣＭＬメンバの第２の集合が、第２の時間期間中に分散データベースを実施することができる。その場合に、ＣＭＬ１３０１を更新する前に、ＣＭＬ１３０１のコピーが、以前のメンバシップ・リスト（ＰＭＬ）１３０７内に記憶され、その後、ＣＭＬ１３０１が更新される。ＰＭＬ１３０７は、データ構造または他の論理的におよび／もしくは物理的に実施されるコンテナとして実施され得る。ＰＭＬ１３０７は、分散データベースの以前の状態に関連するメンバの属性を含むように構成される。

［１１８９］デジタル署名が、創設メンバごとに、および最終的に分散データベースに追加された非創設メンバに関して、生成される。各メンバは、彼らの秘密鍵を使用してＤ２ＩＤにデジタル署名する。たとえば、アリスのデジタル署名は、Ｓｉｇｎ（Ａ＿Ｐｒｉｖａｔｅ＿Ｋｅｙ，Ｄ２ＩＤ）の結果であり、ここで、Ａ＿Ｐｒｉｖａｔｅ＿Ｋｅｙは、アリスの秘密鍵であり、Ｄ２ＩＤは、分散データベースの名前または一意識別子である。他の例では、アリスは、アリスの一意識別子および彼女の署名を有する対、たとえば（Ａ＿ＩＤ，Ｓｉｇｎ（Ａ＿ＩＤ，Ａ＿Ｐｒｉｖａｔｅ＿Ｋｅｙ，Ｄ２ＩＤ））を生成し、ここで、識別子Ａ＿ＩＤは、彼女の公開鍵、名前、デジタル証明書、または他の適切な識別子とすることができる。

［１１９０］いくつかの実施態様では、デジタル署名は、メンバの間で署名付きメッセージを送るのに使用される。したがって、署名付きメッセージは、関数Ｓｉｇｎ（Ｋ，Ｍ）の結果を含むことができ、ここで、Ｋは、秘密鍵、たとえばアリスに関連する「Ａ＿Ｐｒｉｖａｔｅ＿Ｋｅｙ」であり、Ｍは、メッセージ（ＭＳＧ）である。いくつかの例では、メッセージ「ＭＳＧ」は、ハッシュ化され連結されたデータの関数、たとえばＭＳＧ＝ｈａｓｈ（ｘ，ｙ，ｚ）とすることができ、ここで、ｘ、ｙ、およびｚは、分散データベースのメンバの間で交換される任意のタイプのデータ（たとえば、イベント、分散データベース状態、動作など）とすることができる。したがって、メンバは、メッセージＭＳＧが、たとえばＫ＝Ａ＿Ｐｒｉｖａｔｅ＿Ｋｅｙであるときにアリスによって署名されることを示す、（ＭＳＧ，Ｓｉｇｎ（Ｋ，ＭＳＧ））の形の署名付きメッセージを送ることができる。

［１１９１］いくつかの例では、メンバシップ１３０３および分散データベース・データ１３０８は、２つの論理的に独立なエンティティまたはデータ構造（たとえば、異なるデータベース、異なる論理的に分離されたデータベース部分（たとえば、テーブル）、単一のデータベース内の異なるデータ構造など）である。たとえば、メンバシップ１３０３は、Ｄ２ＩＤ１３０９に関連する現在のメンバおよび以前のメンバを含むが、分散データベース・データ１３０８は、すべての作成され、かつ／または受信されたイベントとそのようなイベント内に含まれるトランザクションまたは動作とを含む、分散データベースの現在の状態１３１１に関連するデータを含む。他の例では、メンバシップ１３０３および分散データベース・データ１３０８は、単一の論理エンティティまたはデータ構造の一部とすることができる。

［１１９２］図１３内に図示されていない分散データベースに関連する他のデータ構造は、たとえば、更新、新しいメンバの追加、メンバの除去など、分散データベースに対して実行された動作に基づいて作られた識別子および／またはそのような動作の結果、ならびに他の適切なデータ構造および／または経時的に分散データベースに対して実行された動作を含むことができる。いくつかの例では、そのような動作は、分散データベースの状態および／またはメンバのヒストリを提供することができる。たとえば、ＡＤＤ動作は、分散データベースに新しいメンバを追加するのに使用され得る。これは、分散データベースに参加する新しいメンバの識別子（たとえば、秘密鍵、公開鍵、および／またはデジタル署名）のリストを作ることができる。別の例として、ＲＥＭＯＶＥ動作は、分散データベースから１つまたは複数の現在のメンバを除去することができる。これは、分散データベースから除去されようとしているメンバに関連する識別子（たとえば、秘密鍵、公開鍵、および／またはデジタル署名）の集合を無効化しまたは除去することができる。

［１１９３］上で議論したように、分散データベースの状態は、同意に達した後に定義され得る。たとえば、ラウンドＲの有名な目撃者のすべてが識別され、かつ／または知られた後に、Ｒの受信されたラウンドを有するイベントの集合Ｓ（Ｒ）を計算し、それらの同意順序およびそれらの同意タイムスタンプを計算することが可能である。その後、状態ＳＴＡＴＥ（Ｒ）が計算され得、これは、Ｒまたはより以前の受信されたラウンドを有するイベント内のトランザクションから生じるデータベース状態である。その点で、Ｓ（Ｒ）内のイベントの同意順序は、既知であり、変化しない。したがって、時刻Ｔ_１に、分散データベース状態の初期状態１３１１は、Ｔ_１の後、Ｔ_２の前に、ＳＴＡＴＥ（Ｒ）＝「ＳＴＡＴＥ１」とすることができる。いくつかの例では、この状態は、本明細書でさらに詳細に議論するように、署名付きハッシュ値とすることができる。

［１１９４］各データベース動作は、分散データベースを実施する計算デバイスで生成された所与のイベント内のトランザクションによって開始され得る。分散データベース動作は、受信されたラウンド番号Ｒに関連する。たとえば、受信されたラウンドＲ＝３を有するイベント内のトランザクションが、データベース動作（たとえば、ＡＤＤ、ＲＥＭＯＶＥ、またはＵＰＤＡＴＥ）を開始する場合に、そのようなデータベース動作は、イベントの受信されたラウンドＲ＝３に関連する。いくつかの実施態様では、ＵＰＤＡＴＥ動作が、受信されたラウンド＝３を有するイベント内のトランザクション内でサブミットされるときに、新しい分散データベース構成が作られる。いくつかの例では、新しい分散データベース構成は、受信されたラウンドＲ＝３中に開始されたＡＤＤ動作に基づいて分散データベースにメンバを組み込み、受信されたラウンドＲ＝３中に開始されたＲＥＭＯＶＥ動作に基づいて分散データベースからメンバを除外する。そのような例では、受信されたラウンドＲ＝３は、受信されたラウンド番号しきい値と呼ばれ得る。その場合に、Ｒ＝３以下の受信されたラウンド番号を有するイベント内の同意プロセスおよびトランザクションは、より古いまたは以前の分散データベース構成または状態に従って実行される。さらに、Ｒ＝３を超える受信されたラウンドを有するイベント内の同意プロセスおよびトランザクションは、新しい分散データベース構成を用いて実行される。たとえば、「強く見る」という概念（上で説明した）は、ある条件が母集団の２／３超によって満足されるかどうかの判定の結果とすることができる。したがって、所与の受信されたラウンドの全母集団内に何個のメンバがあるのかをカウントすることが必要である。たとえば、新しいメンバ・ジョンを分散データベースに追加するように構成されたＡＤＤ動作が、受信されたラウンドＲ＝３に分散データベースによって受信される場合に、作成されたラウンドＲ＝３またはより以前の強く見る目撃者および有名な目撃者に関する判定に関して母集団のサイズを判定するときに、ジョンは、分散データベースによって考慮されない。その場合には、以前のメンバシップ・リスト（すなわち、より古いまたは以前の分散データベース構成のデータベース構成内のメンバシップ・リスト）が、作成されたラウンドＲ＝３およびより以前の同意関連投票および収束での目撃者のラウンド番号を計算するのに使用される。新しいメンバシップ・リストは、作成されたラウンドＲ＝３目撃者の後のイベントに関して、ならびに関連する投票および収束に関して、作成されたラウンド番号を計算するのに使用される。上の例では、ジョンは、母集団のサイズを判定するときに分散データベースによって考慮されないが、彼のイベントは、受信されたラウンドＲ＝３の前に使用され得る。たとえば、ジョンのイベントは、あるイベントとそのイベントを見る先祖イベントとの間の経路の一部とされ得る。したがって、ジョンおよびジョンのイベント自体は、「強く見る」しきい値（上で説明した）に達するために子孫イベントによって使用され得ないが、子孫イベントは、それでも、「強く見る」しきい値に達するために、ジョンのイベントを通る経路に基づいて、それが見ることのできるイベントを使用することができる。

［１１９５］上で議論したように、作成されたラウンドＲ＝３内の有名な目撃者の完全なリストが識別された後に、Ｒ＝３の受信されたラウンドを有する分散データセットにジョンを追加するために開始されたＡＤＤ動作は、ＵＰＤＡＴＥ動作の際に効力を生じる。したがって、ジョンがメンバとして含まれる分散データベースの新しい構成が、生成される。ＡＤＤ動作およびＲＥＭＯＶＥ動作は、分散データベース内に登録された母集団の１つまたは複数のメンバを含めまたは除外し、これは、１つまたは複数のしきい値が満足される（たとえば、「母集団の２／３超」になるように構成された同意しきい値）かどうかを判定するのにメンバ・リスト内の何個のメンバ（またはステーク値）が使用されるのかを変更する。この新しいしきい値は、作成されたラウンドＲ＝３（たとえば、受信されたラウンド番号しきい値）内の目撃者より後のイベントのラウンド番号（すなわち、作成済みラウンド）を再計算し、作成されたラウンドＲ＝４およびより後の目撃者の有名を計算するのに使用される。したがって、たとえば、所与のイベントは、作成されたラウンドＲ＝３目撃者の有名を計算する間に１つの「作成済みラウンド」を有し、その後、作成されたラウンドＲ＝４目撃者の有名を計算する間に異なる「作成済みラウンド」を有することができる。

［１１９６］いくつかの例では、ＡＤＤ動作、ＲＥＭＯＶＥ動作、および／またはＵＰＤＡＴＥ動作は、しきい個数のメンバのデジタル署名（署名しきい値とも称する）によって有効化され得る。たとえば、ＵＰＤＡＴＥ動作は、ＵＰＤＡＴＥ動作の受信直前に分散データベースの一部であったメンバの２／３超がその動作に署名する場合に、有効であると判定される。分散データベース動作の実行に関するさらなる詳細は、図１４を参照して議論する。

［１１９７］本明細書では、ＵＰＤＡＴＥ動作が実行される時の新しい構成の実施として説明されるが、他の例では、新しい構成は、自動的に（すなわち、明示的なＵＰＤＡＴＥ命令なしで）実施される。具体的には、特定の受信されたラウンドＲを有するすべてのイベントが識別された後に、新しい構成は、そのようなイベントに基づいて、受信されたラウンドＲ＋１を有するイベントを識別するために実施され得る。具体的には、受信されたラウンドＲを含むと判定されるイベントがＡＤＤ命令またはＲＥＭＯＶＥ命令を含む場合に、分散データベースの構成は、Ｒを超える（すなわち、受信されたラウンド番号しきい値を超える）受信されたラウンドを計算するために、自動的に変化することができる。

［１１９８］いくつかの例では、ＡＤＤおよびＲＥＭＯＶＥなどのデータベース動作は、分散データベースの所与の状態の同意に達するのに使用される１つまたは複数の投票しきい値を変更する。たとえば、分散データベースは、１から１０までの受信されたラウンドを計算した（すなわち、ラウンド１０またはその前に作成されたすべての有名な目撃者が、既知であり、票は、それでも、作成されたラウンド１１目撃者の一部が有名であるかどうかを判定するために投じられている）。それに関して受信されたラウンドがまだ計算され得ない作成されたラウンド５を有するイベントＸが、生成され得る。その場合に、作成されたラウンド１０以下を有する有名な目撃者が既に識別されているので、イベントＸは、１１未満の受信されたラウンドを有しない。イベントＸが、たとえば、分散データベースの現在のメンバシップ・リストにフランクをＡＤＤするトランザクションを含む場合に、フランクは、作成されたラウンド１１に関連する有名な目迎者を判定するための投票中にはメンバとしてカウントされず、フランクによって定義されたイベントは、作成されたラウンド１１内の各目撃者の有名が識別され得る、より後に作成されたラウンドまで、票を得る目撃者としてカウントされない。その場合に、１１の受信されたラウンドを有するすべてのイベントが、その後に判定され得る。たとえば、イベントＸが、１１の受信されたラウンドを有すると判定される場合に、フランクは、現在のメンバシップ・リストに追加される。

［１１９９］投票しきい値（たとえば、上で説明したＭ）は、追加のメンバ（すなわち、フランク）を含むように再計算され得る。その結果、ラウンド１１より後（受信されたラウンド番号しきい値を超えるラウンド）のイベントについて計算された作成されたラウンドは、フランクを含む新しいしきい値を使用して再計算され得る。いくつかの例では、そのような再計算プロセスは、どのイベントが、たとえば作成されたラウンド１２目撃者および／またはより後の作成されたラウンドに関連する目撃者であると判定されるのかを変更することができる。その後、票が、作成されたラウンド１２目撃者のどれが有名であるのかを判定するために投じられ得る。したがって、現在のメンバシップ・リストは、すべての作成されたラウンド１２の有名な目撃者が識別されるまで、再びは変化しない。この点で、どのイベントが１２の受信されたラウンド（第２の受信されたラウンド番号しきい値とされ得る）を有するのかが、判定され得る。これらのイベントの一部は、現在のメンバシップ・リストからメンバをＡＤＤまたはＲＥＭＯＶＥすることができ、それに応じて、この例で議論される他のより後のイベントに対する同様の変更をトリガすることができる。

［１２００］いくつかの例で、分散データベースのメンバは、所与の時点に（または所与の受信されたラウンドで）分散データベースの「署名付きの状態」を判定する。「状態」または「現在の状態」は、同意トランザクションのシーケンスの、それらの同意順序での（すなわち、各トランザクションを含むイベントの同意順序に従ってソートされ、トランザクションが各イベント内に含まれる順序によってサブソートされての）実行から生じる情報を含む。メンバが、Ｒまでの受信されたラウンドに関連するイベントの同意順序を計算した後に、そのようなメンバは、同意順序のトランザクションから生じる状態または現在の状態にデジタル署名する（または状態もしくは現在の状態に関連するハッシュ値にデジタル署名する）（たとえば、秘密鍵を使用して）ことができる。オプションでまたはその代わりに、メンバは、受信されたラウンドの部分集合だけに関する状態に署名することができる。たとえば、Ｒが、所与の整数によって割り切れるときに（たとえば、５つおきのラウンド）、または分散データベースの各メンバに指定された時間しきい値に従って（たとえば、１秒ごとに）、メンバは、受信されたラウンド番号Ｒに関連する状態に署名するように割り当てられ得る。

［１２０１］いくつかの実施態様では、受信されたラウンドＲの「署名付きの状態」は、１）受信されたラウンド番号Ｒ、２）署名付きの状態に影響する同意の一部であった各メンバによって生成された最後のイベント（すなわち、Ｒまたはより早い受信されたラウンドを有するイベント）のシーケンス番号およびハッシュ値、３）Ｒを含めてＲまでの受信されたラウンドの同意順序でのトランザクションの影響を反映するデータ構造、４）メンバシップ・リストの２／３超（いくつかの例では、たとえば１／２超など、異なるしきい値が使用され得る）による署名を有するより以前の状態に対するデジタル署名（または合意の他の表示）の集合、ならびに／または５）「メンバシップ・ヒストリ」という項目のうちの１つまたは複数を含む。いくつかの実施態様では、これらの要素の一部が、欠けている場合がある（たとえば、番号４）。いくつかの実施態様では、たとえば、「状態」は、メンバシップ・ヒストリ以外の上記のすべてのハッシュと、メンバシップ・ヒストリの別々のハッシュとを含む。そのような実施態様では、メンバは、「署名付きの状態」を生じるために、ハッシュの対にデジタル署名する（秘密鍵を用いて）ことができる。

［１２０２］いくつかの実施態様では、第１のメンバが状態に署名するときに、デジタル署名、状態のハッシュ、および受信されたラウンド番号を有するトランザクションが生成される。そのようなトランザクションは、第１のメンバによって作成され、かつ／または定義される次のイベント内に含まれるように構成される。その後、第１のメンバは、イベントを保存し、かつ／または分散データベースにポストすることができる。その後、第１のメンバとは異なる他のメンバは、第１のメンバのデジタル署名を認識し、記録する。第２のメンバが、しきい値を超える、所与の状態に関連する第１のメンバおよび他のメンバのデジタル署名を含む複数のデジタル署名を他のメンバから受信するときに、第２のメンバは、これを同意署名付きの状態として識別することができる。第２のメンバは、デジタル署名の個数が署名しきい値に達するかどうか（たとえば、所与の状態が、分散データベース内のメンバの２／３超のデジタル署名によって支持されるかどうか）を判定し、あるいは、分散データベースの他のメンバから合意の表示を他の形で受信することができる。デジタル署名の個数が署名しきい値に達した後に、その状態は、「署名付きの状態」になる。メンバが署名付きの状態を有した後に、それらは、その署名付きの状態に寄与したすべてのイベントを破棄し、すべての以前の署名付きの状態を破棄することができる。したがって、そのようなイベントおよび以前の署名付きの状態の記憶専用のメモリ割振りが、解放され、ハッシュグラフによって使用されるストレージの量を減らすことができる。いくつかの実施態様では、古いイベントは、即座に破棄されるのではなく、ある個数の追加の受信されたラウンドが同意の一部になった後および／または所定の時間期間の後に限って破棄される。

［１２０３］いくつかの例では、イベントは、以下の判断基準を使用して定義され得る。１）「イベント」は、その自己親のシーケンス番号より１つ大きいシーケンス番号（または、自己親がない場合には０）を有し（上で説明したように）、２）「イベント」は、親ごとに「作成済みラウンド」を含み（したがって、イベントは、各親のハッシュを含むだけではなく、その親からコピーした作成済みラウンドをも含む）、かつ、３）イベントは、各親の作成済みラウンドのうちの最大値である「親ラウンド」を有する（したがって、イベントの「作成済みラウンド」は、そのイベントの親ラウンドに０または１のいずれかを加えたものと等しい）。

［１２０４］いくつかの例では、この例において「Ａ」と称する大域定数「年齢しきい値」が、あるイベントが同意プロセス内で考慮されるか否かを判定するのに使用される。たとえば、Ａ＝４を仮定し、あるイベントがＲの親ラウンドを有し、そのイベントの受信されたラウンドがＲ＋Ａより後である場合には、１）そのイベントは、同意順序の一部ではなく、２）そのイベントのトランザクションは、無視され、同意状態に影響せず、３）そのイベントは、そのイベントがラウンドＲ＋Ａまたはそれより以前に受信されなかったことを知っている任意のメンバによって破棄され得、４）そのイベントは、フォークの一部である場合であっても、ラウンドＲ＋Ａまたはより後に「見ること」を妨げない。たとえば、アリスが、少なくともラウンドＲ＋Ａまでのラウンドの間に、イベントＸがこれらのラウンドのいずれにおいても受信されずに有名な目撃者を既に計算した後に、アリスが、同期化プロセス中にイベントＸを受信する場合に、アリスは、イベントＸを破棄することができる。いくつかの例では、図１６を参照して下で詳細に議論するように、アリスによるイベントＸの破棄が、所与の作成者による既知のイベントの集合が不連続なシーケンス番号を有することを引き起こす場合には、イベントＸは、アリスによって破棄されないはずである。

［１２０５］図１３は、分散データベースの初期状態を示すが、図１４は、一実施形態による、初期状態が定義された後に分散データベース内で実行されるＵＰＤＡＴＥ動作、ＡＤＤ動作、およびＲＥＭＯＶＥ動作の例を示す流れ図である。いくつかの例では、分散データベースが、図１３に示されているように初期化された後に、１つまたは複数の動作が、分散データベース内に含まれるメンバを変更するために分散データベース内で実行され得る。たとえば、１４２１で、分散データベースＤ２ＩＤがＳＴＡＴＥ（Ｒ）＝「ＳＷ１」を有し（ＳＷ１は、分散データベースＤ２ＩＤの初期ハッシュグラフに関連する分散データベースの現在の構成である）、受信されたラウンド番号Ｒが、最も最近に計算され、かつ／または識別された受信されたラウンドであると仮定すると、１４２３で、ジョン、ジャニス、およびチャドが、初期化されたＡＤＤ機能を介して、分散データベースのメンバとして追加されるように構成される。構成ＳＷ１は、イベントの順序および／または収束を判定するときにジョン、ジャニス、およびチャドを含まない、上で議論したイベント同意プロトコルの構成（または同意順序）を含む。いくつかの例では、１４２３でのＡＤＤ機能は、パラメータとしてジョン、ジャニス、およびチャドの公開鍵をとることができる。この点で、新しいメンバのそれぞれは、関連する秘密鍵をも有する。１４２５に示されているように、メンバ（たとえば、アリス）が、分散データベースから除去されることも可能であり、この場合には、ＲＥＭＯＶＥ動作は、アリスの公開鍵をパラメータとして用いて初期化される。いくつかの例では、ＡＤＤ動作およびＲＥＭＯＶＥ動作は、分散データベースを実施するメンバ（計算デバイス）において、イベントの集合内のトランザクションとして受信され得る。ＡＤＤ動作および／またはＲＥＭＯＶＥ動作が指定された受信されたラウンド番号を有するイベント内のトランザクションによって引き起こされた時を判定できるように、ＡＤＤ動作およびＲＥＭＯＶＥ動作は、それらの受信されたラウンド番号に関連付けられる。

［１２０６］受信されたラウンド番号Ｒに関連するＵＰＤＡＴＥ動作、たとえば１４２７のＵＰＤＡＴＥ動作中に、現在の分散データベース構成ＳＷ１（アリスを含むが、ジョン、ジャニス、およびチャドを含まない）は、変数ＰｒｅｖＳＷに保存され、ＰｒｅｖＳＷ構成に関連する分散データベースのメンバは、受信されたラウンド番号Ｒに関連する以前のメンバシップ・リスト内に記憶され得る。いくつかの代替実施態様では、ＰｒｅｖＳＷは、複数の以前の分散データベース構成を含むオブジェクトの配列とすることができる。新しい分散データベース構成ＳＷ２は、受信されたラウンドＲでのＵＰＤＡＴＥ動作の実行に基づいて生成され得る、すなわち、ＳＴＡＴＥ（Ｒ）＝「ＳＷ２」である。したがって、変数ＣｕｒｒｅｎｔＳＷは、新しい分散データベース構成ＳＷ２（イベント同意プロトコルに新しい構成を使用する）を含むように更新される。

［１２０７］構成ＳＷ２は、ジョン、ジャニス、およびチャドを含むが、アリスを含まず、したがって、アリスは、分散データベースが構成ＳＷ２を使用するときに、同意順序または収束の判定に含まれない。言い換えると、更新された分散データベース構成ＳＷ２は、変更された分散データベース構成（たとえば、新しいメンバ、ジョン、ジャニス、およびチャドの追加とアリスの除去と）を反映するように構成された現在のメンバ・リストに対する変更を反映する。いくつかの例では、ジョン、ジャニス、およびチャドの新しい鍵対を含み、アリスを除外したメンバの鍵対の更新された集合は、現在の分散データベース構成ＣｕｒｒｅｎｔＳＷ内に含まれる。いくつかの例では、この時の分散データベース状態は、ＡＤＤ動作、ＲＥＭＯＶＥ動作、ＵＰＤＡＴＥ動作、および／または他の適切な動作を含む、更新の時刻までに分散データベースに対して実行された動作をも含むことができる。

［１２０８］いくつかの例では、分散データベースの現在のメンバシップ・リストのメンバが、たとえばＡＤＤ動作、ＲＥＭＯＶＥ動作、ＵＰＤＡＴＥ動作、および／または他の適当な動作を介して変化した場合に、イベントは、分散データベースの異なる構成に従って処理され得る。図１４に示された例では、１４２９でイベントが受信されるときに、そのようなイベントに関連する受信されたラウンドＲ’が、識別され、かつ／または計算される。たとえば、１４３１に示されているように、イベントの受信されたラウンドＲ’が、分散データベースが動作している受信されたラウンドＲ以下であると識別される場合には、そのようなイベントは、たとえば、分散データベースの以前の構成バージョンに関連する以前のメンバシップ・リスト（たとえば、図１３を参照して議論した以前のメンバシップ・リスト１３０７内に記憶されたメンバシップ・リスト）を用いて処理される。言い換えると、１４３３で、イベントは、たとえばアリス、ボブ、キャロル、デイブ、およびエドを含むがジョン、ジャニス、およびチャドを含まないメンバシップ・リストを有する分散データベース構成ＳＷ１（上で説明した）を使用して、同意または収束に関して処理される。反対のシナリオでは、１４３５で、イベントの受信されたラウンド番号が、構成が変化した（たとえば、そのような作成されたラウンドおよびそれ未満のラウンドを有する有名な目撃者のすべてが、既に識別されており、イベントが、それらのうちの十分な数によって受信されるのをまだ見られていない）受信されたラウンド番号を超えるときに、そのようなイベントは、分散データベースの更新されたバージョンを用いて処理される。すなわち、アリスを除いてボブ、キャロル、デイブ、エド、ジョン、ジャニス、およびチャドを含む現在のメンバシップ・リストを有する分散データベース構成ＳＷ２である。したがって、いくつかの例では、イベントの順序は、分散データベースの複数の構成（またはイベント同意プロトコルの構成）、したがって分散データベースのインスタンスの新しい状態に基づいて判定され得る。上で議論したように、ハッシュ値は、分散データベースの状態に関して計算され、分散データベースのメンバの秘密鍵を使用して署名され得る。メンバ、たとえば分散データベースの状態に署名したメンバは、新しい署名付きの状態を示すトランザクションを含むイベントを分散データベースのインスタンス内にポストするために信号を送ることができる。

［１２０９］いくつかの例では、分散データベースのメンバは、１つまたは複数のイベント内に含まれるトランザクション（またはトランザクションの集合）としてＵＰＤＡＴＥ動作、ＡＤＤ動作、および／またはＲＥＭＯＶＥ動作を保存し、かつ／またはこれらを分散データベースにポストすることができる。その後、このイベントは、分散データベースの別のメンバに送られ得る（たとえば、同期化プロセスの一部として）。たとえば、第１のメンバは、同期化プロセスの一部として分散データベースの第２のメンバによって送られたイベント内に含まれるトランザクション内で、分散データベースに新しいメンバをＡＤＤする動作を受信することができる。別の例として、第１のメンバは、同期化プロセスの一部として第３のメンバによって送られたイベント内に含まれるトランザクション内で、分散データベースからメンバをＲＥＭＯＶＥする動作を受信することができる。言い換えると、分散データベースの各メンバは、ＵＰＤＡＴＥ動作、ＡＤＤ動作、および／またはＲＥＭＯＶＥ動作のいずれかを含むトランザクションを有するイベントを定義し、そのようなイベントを、同期化プロセスの一部として分散データベースの他のメンバに送ることができる。

［１２１０］図１４に示されたプロセスは、各新しい受信されたラウンド内のイベントに関して繰り返され、更新され得る。したがって、受信されたラウンドがイベントごとに識別されるときに、分散データベースの構成（またはイベント同意プロトコルの構成）は、更新され得る。さらに、上では２つの構成に関して説明されるが、ＳＴＡＴＥ（Ｒ）＝「ＳＷ３」を有する分散データベースの後続の構成（および追加の将来の構成）は、ＳＷ２に関して説明されたものに類似する形で定義され得る。したがって、いくつかの例では、分散データベースは、第３の分散データベース構成（たとえば、イベント同意プロトコルに関する第３の構成を使用する）を使用して動作することができる。したがって、分散データベースは、そのようなトランザクションを有する新しいイベントが分散データベースにポストされるときに、新しい構成を用いて定義し、かつ／または動作し続けることができる。

［１２１１］上では、分散データベースへのメンバの追加および／またはこれからのメンバの除去に基づく分散データベースの構成（またはイベント同意プロトコルの構成）の更新として説明されるが、いくつかの例では、構成は、同意を判定するのに使用される新しいソフトウェアおよび／または同意を判定するための新しいルールに基づいて、メンバに関連するおよび／またはメンバに論理的に関係付けられたステーク値の変化に基づいて更新され得る。たとえば、トランザクションが実行されるときに、各メンバのステーク値が変化する可能性がある。ステーク値に基づいて同意を判定する分散データベースの実施態様では、これが、同意プロトコル（たとえば、有名な目撃者の判定）に影響する可能性がある。したがって、１つまたは複数のメンバのステーク値を変更するイベントの受信されたラウンド（受信されたラウンド番号しきい値として使用される）に依存して、異なるラウンド内のイベントの順序は、図１４のプロセスに類似する異なる構成に基づいて判定される。別の例として、同意を判定するソフトウェアに対する更新および／または同意を判定するルールに対する更新は、そのような更新を含んだイベントの受信されたラウンド（受信されたラウンド番号しきい値として使用される）に基づいて、有効になり、かつ／または使用され得る（図１４のプロセスに類似する）。

［１２１２］図１５および図１６に示されたプロセスは、分散データベースの２つのメンバの間でのイベントの同期化中に実行され得る。図１５は、受信されたラウンドに基づくイベントの受諾および拒絶を示す流れ図である。いくつかの例では、たとえば、異なるメンバに関連する分散データベースの同期化中に、イベントは、（１）すべての有名な目撃者がその中で識別され、かつ／または決定された最も最近のラウンド番号Ｒ、（２）イベントがその親としてリストする親ｅｖｅｎｔ．Ｐａｒｅｎｔ［ｉ］のそれぞれ、および（３）イベントがその親の作成されたラウンドとしてリストする各対応するｅｖｅｎｔ．ＰａｒｅｎｔＲｏｕｎｄＣｒｅａｔｅｄ［ｉ］に基づいて拒絶されまたは受諾され得る。実際の親が、受信された子イベント内でその親に関してリストされた作成済みラウンドとは異なる作成済みラウンドを有する場合があることに留意されたい。これは、イベントの作成済みラウンドが、メンバが追加され、除去されるときに変化する可能性があり、したがって、親が、子が作成されたときに受信される１つのラウンドと、より後の時刻の異なるラウンドとを有することが可能であるからである。メンバは、ＰａｒｅｎｔＲｏｕｎｄＣｒｅａｔｅｄ数の割当においてできる限り正確であるというタスクを割り当てられる。

［１２１３］計算負荷およびメモリ・リソースは、いくつかの例で有利に減らされ得る。たとえば、第１のメンバ（たとえば、第１の計算デバイス）が、１５５１で、分散データベースのそのローカル・インスタンスで分散データベースの第２のメンバ（たとえば、第２の計算デバイス）からイベントを受信する時である。そのようなイベントは、親イベントの集合を表示するバイトのシーケンスを含むことができる。親イベントの集合からの各親イベントは、ハッシュ値および作成済みラウンド値に論理的に関係付けられ得る。１５５３で、第１の判断基準が満足されるかどうかを判定するために、第１のメンバは、（１）受信されたイベントの少なくとも１つの親（受信されたイベント内で示される）が、第１のメンバの分散データベースのインスタンスに不在であるかどうか、および（２）受信されたイベントの親が、Ｒから所定のしきい値（たとえば、Ｔｈｒｅｓｈｏｌｄ１）を減じた値を超える、受信されたイベント内のリストされた作成済みラウンドを有するかどうかを判定する。いくつかの例では、イベントがこれらの条件を満足する（すなわち、第１の判断基準を満足する）ときに、第１のメンバは、１５５９で、イベントを拒絶しまたは除外する。たとえば、イベントが、Ｒ−Ｔｈｒｅｓｈｏｌｄ１以下（すなわち、第１の作成済みラウンドしきい値Ｒ−Ｔｈｒｅｓｈｏｌｄ１以下）であるリストされた作成済みラウンドを有する親を有するときに、その親は、既に破棄されていると仮定され得（たとえば、破棄済みになるのに十分に古い）、したがって、受信されたイベントは、潜在的に、欠けている親にもかかわらず受諾され得る（下で説明するステップ１５５５に依存して）。しかし、破棄済みになるのに十分には古くない、欠けている親がある場合には、その親が欠けているので、イベントは、１５５９で拒絶され得る。いくつかの実施態様では、１５５３で、イベントが条件を満足しないときに、イベントは、１５５５で、イベントの各親がＲから所定のしきい値を減じた値の前（すなわち、第２の作成済みラウンドしきい値Ｒ−Ｔｈｒｅｓｈｏｌｄ２未満）のリストされた作成済みラウンドを有するかどうかを判定するために、第２の判断基準に関して評価される。そうである場合（すなわち、第２の判断基準が満足される場合）には、イベントは、１５５９で拒絶されまたは除外され、そうでない場合には、１５５７で受諾される。この決定は、イベントが（たとえば、同意を判定するのにおよび／または分散データベースの状態に影響を与えるのに）使用されなくなることが明瞭になるときに、イベントが破棄されることを可能にする。たとえば、すべてのリストされた親が非常に古い場合に、受信されたイベント自体は、破棄されるのに十分に古いと考えられ、したがって、受信されるや否や、破棄され得る。これらの例では、非常に古いイベント（Ｔｈｒｅｓｈｏｌｄ１に基づいて）を除いて、親のすべてが存在し、イベント自体が非常に古くはない（Ｔｈｒｅｓｈｏｌｄ２に基づいて）場合に、受信されたイベントは受諾される。第１のメンバ（すなわち、第１の計算デバイス）は、分散データベースのインスタンス内に、１５５７で受諾されたイベント（すなわち、１５５９で拒絶も除外もされなかったイベント）を記憶することができる。いくつかの実施態様では、Ｔｈｒｅｓｈｏｌｄ１および／またはＴｈｒｅｓｈｏｌｄ２は、分散データベースのメンバによって事前に定義され得る。いくつかの実施態様では、Ｔｈｒｅｓｈｏｌｄ１は、Ｔｈｒｅｓｈｏｌｄ２と同一の値または異なる値を有することができる。

［１２１４］図１６は、分散データベースの２つのメンバの間でのイベント同期化中に実行される検証プロセスを示す流れ図である。第１のメンバまたは第１の計算デバイスは、同期化プロセスを開始するために、分散データベースの他のメンバに同期化要求を送ることができる。いくつかの実施態様では、分散データベースの第１のメンバと第２のメンバとの間の同期化は、下で説明するように実行される。たとえば、第１のメンバがボブであり、第２のメンバがアリスである場合には、同期化は、アリスが分散データベースの所与の構成でメンバごとに受信した最初および最後のシーケンス番号および／またはシーケンス値に基づいて実行され得る。そのようなシーケンス番号および／またはシーケンス値は、メンバの間で同期化要求内で送られ得、メンバは、他のメンバによってまだ受信されず、かつ／または記憶されていないイベントを交換することができる。したがって、いくつかの例では、既に受信され、かつ／または記憶されたイベントは、交換されず、同期化プロセス中に使用される帯域幅を減らす。

［１２１５］アリスの展望から、彼女は、ボブ、キャロル、エド、およびデイブによって作成され、かつ／または定義されたイベントに関して彼女が有する最初および最後のシーケンス番号を使用することができる。したがって、たとえば、アリスは、分散データベースの彼女のインスタンスで受信されたイベント（たとえば、分散データベースのエドのインスタンスによって作成され、かつ／または定義されたイベント）に基づいて、エドに関して分散データベースのアリスのインスタンスで受信されたイベントの最後のシーケンス番号より大きいシーケンス番号を有するエドによって定義されたイベントが、アリスがまだ受信していないイベントであると判定することができる。その後、ボブは、これらのイベントをアリスに送ることができる。同様に、アリスは、所与のメンバ、たとえばエドに関して分散データベースのアリスのインスタンスで受信されたイベントに基づいて、分散データベースのアリスのインスタンスで記憶されたそのメンバの最初のシーケンス番号より小さいシーケンス番号を有する、そのメンバに関してボブによって記憶されたすべてのイベントが、分散データベースのアリスのインスタンスが拒絶しまたは破棄したイベントであると判定することができる（たとえば、上で説明した署名付きの状態に基づいて）。

［１２１６］いくつかの実施態様では、アリス（または任意の他のメンバ）は、そのシーケンス番号が、所与のメンバ（たとえば、エド）に関して分散データベースのアリスのインスタンスで記憶されたイベントの最初のシーケンス番号と最後のシーケンス番号との間であるイベントを破棄せず、拒絶しない。他の例では、同期化中に、分散データベースのアリスのインスタンスは、図１５を参照して議論したように、署名付きの状態の一部である古いイベント、または、１つもしくは複数のしきい値によって定義される範囲内の受信されたラウンド番号を有しないイベントのいずれをも破棄することができる。

［１２１７］同期化中に、第１のメンバ（たとえば、アリス）に関連する分散データベースのローカル・インスタンスは、ボブからのイベントが、分散データベースのアリスのローカル・インスタンスで彼女がまだ受信していない親イベントのハッシュ値を含む場合に、そのようなイベントを拒絶することができる。しかし、いくつかの例で、アリスに関連する分散データベースのローカル・インスタンスは、イベント親がアリスに関連する分散データベースのローカル・インスタンス内に含まれない場合であっても、たとえばアリスが受信されたイベントの親を破棄したことの表示がある場合に、そのようなイベントを受諾することができる。アリスに関連するデータベースのローカル・インスタンスが一般に破棄するはずのイベントの例は、イベントが分散データベースの状態に対する影響を有しておらず、かつ／またはその影響がアリスに関連する分散データベースのローカル・インスタンス内の最新の署名付き状態に既に組み込まれているので、イベントが破棄され得るとアリスが判定できるような、十分に古い受信されたラウンド番号に関連する親を有するイベントを含む。

［１２１８］いくつかの例で、第１のメンバ（たとえば、アリス）は、１６０１で、分散データベースの彼女のローカル・インスタンスで、分散データベースの非ローカル・インスタンス、たとえばボブに関連する非ローカル・インスタンスからイベントＸを受信する。その後、１６０３で、署名の集合が、イベントＸから抽出され得る。１６０５では、イベントＸから抽出された署名の集合が検証プロセスに合格するか否かを判定するために、署名検証プロセスが実行される。いくつかの例では、イベントＸ（アリスによって受信された）から抽出された署名に基づいて、イベントＸが、たとえば所与の作成者（たとえば、エド）および所与のシーケンス番号（たとえば、ＳＮ＝３）を有する親イベントＹを有し、アリスに関連する分散データベースのローカル・インスタンスが、親イベントＹ、同一の作成者（すなわち、エド）、および同一のシーケンス番号（すなわち、ＳＮ＝３）を有するイベントＺを含むとアリスが判定できるときに、イベントＸは、検証プロセスに合格できない。したがって、フォークするイベントを定義する分散データベースのインスタンスによって引き起こされ得る分散データベース内の異常があるときに、検証プロセスは失敗する。

［１２１９］１６０７では、アリスが、イベントＸが署名検証に失敗したと１６０５で判定するときに、アリスの分散データベースのローカル・インスタンスは、イベントＸが検証プロセスに失敗したことを示す失敗通知メッセージをボブの分散データベースの非ローカル・インスタンスに送る。その後、１６０９では、分散データベースのローカル・インスタンスが、イベントＸの親であるイベントに関連するハッシュ値を受信する。その後、分散データベースのローカル・インスタンスは、イベントＸの親であるイベントに関連する受信されたハッシュ値を比較し、分散データベースの非ローカル・インスタンスに１つまたは複数のイベント、たとえばイベントＸの親であるイベントが欠けているか否かを判定することができる。したがって、１６１１では、分散データベースのローカル・インスタンスは、分散データベースの非ローカル・インスタンスに、分散データベースの非ローカル・インスタンスに欠けているイベントのハッシュを送る。プロセスの流れは、１６０１で始まるループ内で継続する。

［１２２０］いくつかの例で、分散データベースのローカル・インスタンス（たとえば、アリス）によって受信されたイベントが、１６０５で検証プロセスに合格するときには、アリスは、同期化プロセス（たとえば、２つのメンバの間でのイベントの同期化）中にフォーキング問題が識別されたかどうかを判定することができる。フォーキング問題が識別されるときには、分散データベースのローカル・インスタンス（たとえば、アリス）は、分散データベースの非ローカル・インスタンス（たとえば、ボブ）に、識別されたフォーキング問題に含まれ、かつ／またはこれによって影響されると判定されたイベントＸの先祖（たとえば、親）である１つまたは複数のイベントのインジケータ（たとえば、ハッシュ値）を送り、その後、このプロセスは終了する。いくつかの例では、同期化プロセス中にフォーキング問題が識別されない時、たとえば１６０１で受信されたイベントＸが、１６０５での署名検証プロセスに合格するときに、このプロセスは終了する。

［１２２１］いくつかの例では、イベントＸおよびイベントＹは、これらが同一の作成者および同一の作成済みラウンドを有し、どちらもが他方の先祖ではない場合に、お互いとの「フォーク」である。これは、フォークするイベントＸおよびＹが同一の受信されたラウンドを有することを指定する追加の制約を有する、図９を参照して上で議論した「フォーキング」問題の使用の変形形態である。さらに、いくつかの例では、上で説明した「見る」および「強く見る」の定義は、「フォーキング」のこの代替の定義に基づいて変更され得る。たとえば、イベントＸは、イベントＹがイベントＸの先祖であり、イベントＸの先祖でありイベントＹの「フォーク」であるイベントＺがない場合に限って、イベントＹを「見る」ことができる。イベントＸは、分散データベース・メンバのうちのＭ（たとえば、２／３）を超えるメンバによって作成されたイベントの集合Ｓが存在し、イベントＸが、Ｓ内のすべてのイベントを見ることができ、Ｓ内のすべてのイベントがイベントＹを見ることができる場合に限って、イベントＹを「強く見る」ことができる。

［１２２２］フォーキングは、余分な計算および帯域幅使用を引き起こし、したがって、メンバは、そのメンバがフォークするイベントを作成し、かつ／または定義したと判定されるときに、ペナルティを科され得る。したがって、メンバが、フォークするイベントを引き起こしたと判定されるときに、分散データベースは、そのようなメンバにペナルティを科すように構成され得る。そのような例では、フォークを発見するメンバは、そのようなフォークを文書化するトランザクションを作成することができ、このトランザクションは、イベントのフォーキング作成の責任を負うメンバを分散データベースから一時的にまたは永久的に除去するＲＥＭＯＶＥ動作に関するトランザクションとして働く。たとえば、メンバは、そのようなメンバがフォークするイベントを作成したラウンドに対応するラウンドの彼／彼女の票および／またはフォークするイベントを無効にすることによって一時的にペナルティを科され得る。

［１２２３］いくつかの実施態様では、１同期化プロセスあたりのバイト数および／または１同期化プロセスあたりの同期化を許されるイベント数の大域限度が、分散データベース内で実施される。たとえば、アリスが、ボブによって見逃されたイベントをボブに送るときに、アリスに関連するデータベースのインスタンスは、次のイベントが許容できるバイト数または同期化を許されるイベントの許容できる個数のいずれかを超えるときに、データ・パケットおよび／またはイベントの送出を停止することができる。そのようなケースでのイベントの送信は、イベントとそのイベントの親との両方が同期化されつつある場合に、イベントを送る前にイベントの親を送ることによって実行され得る。

［１２２４］いくつかの例では、同期化される２つのイベント、たとえばイベントＸおよびイベントＹが、関係付けられていない（すなわち、どちらもが他方の直接の子孫ではない）ときに、イベントＸの作成者によって作成されたイベントの現在の同期化プロセス中に、第１のメンバに関連するバイト数の大域限度（Ｂｘ）（および、同様に、イベントＹの作成者による第２のメンバに関連するバイトの大域限度（Ｂｙ））に達することをイベントＸの送出が意味する場合に、同期化プロセスは、Ｂｘ＜Ｂｙの場合にイベントＹの前にイベントＸを送ること、Ｂｙ＜Ｂｘの場合にイベントＸの前にイベントＹを送ることを含み、Ｂｘ＝Ｂｙの場合にいずれかの順序でそれらを送ることができる。これは、大きいイベントが同期化プロセスを制御するのを防ぐ。

［１２２５］いくつかの例では、第１のメンバおよび第２のメンバは、各メンバの最初／最後のシーケンス番号のリストを共有することによって同期化プロセスを開始する。第１のメンバが、彼女がその後に破棄したイベントを有したが、第２のメンバがまだこれらのイベントを必要とすることを、それらのメンバが発見する可能性がある。その場合に、第１のメンバが、第１のメンバに関連する分散データベースのインスタンス内に記憶された最新の署名付き状態を第２のメンバに関連するデータベースのインスタンスに送る、同期化プロセスの変更されたバージョンが実行される。その後、第１のメンバは、第２のメンバが既に第２のメンバに関連するデータベースのインスタンス内に有するイベントを除く、最新の署名付き状態の後に登録された、第１のメンバに関連するデータベースのインスタンス内に記憶されたイベントを送る。したがって、第２のメンバは、長い時間期間にわたってデータベースの彼のローカル・インスタンスをスリープさせまたはターンオフする（すなわち、オフラインにする）ことができ、ウェイク・アップまたはターン・オンの後に、同期化プロセスの変更されたバージョンの実行は、第２のメンバが分散データベースに参加することを可能にする。言い換えると、いくつかの例で、第２のメンバは、参加し続けるために、署名付き状態およびその署名付き状態以降のすべてのイベントだけを第１のメンバから受信することができる。これは、署名付き状態なしで交換されるイベントの個数を減らす。

［１２２６］図示され、上で説明された例のシステムは、他のシステムを参照して説明されるが、他の実施形態では、例のシステムおよびそれらの関連する機能性の任意の組合せが、分散データベースを作成し、かつ／または定義するために実施され得る。たとえば、例のシステム１、例のシステム２、および例のシステム３は、分散データベースを作成し、かつ／または定義するために組み合わされ得る。別の例として、いくつかの実施形態では、例のシステム１０は、例のシステム９なしで、例のシステム１を用いて実施され得る。さらなる別の例として、例のシステム７は、例のシステム６と組み合わされ、これを用いて実施され得る。さらなる別の例として、例のシステムの任意の他の適切な組合せが実施され得る。

［１２２７］］様々な実施形態が上で説明されたが、それらが、例としてのみ提示され、限定的ではないことを理解されたい。上で説明された方法が、ある順序で発生するある種のイベントを示す場合に、ある種のイベントの順序付けは、変更され得る。さらに、ある種のイベントは、可能なときには並列プロセス内で同時に実行され得ると同時に、上で説明されたように順次実行され得る。

［１２２８］本明細書で説明されるいくつかの実施形態は、様々なコンピュータ実施される動作を実行する命令またはコンピュータ・コードをその上に有する非一時的コンピュータ可読媒体（非一時的プロセッサ可読媒体と呼ばれることも可能である）を有するコンピュータ・ストレージ製品に関する。コンピュータ可読媒体（またはプロセッサ可読媒体）は、本質的に一時的な伝搬する信号（たとえば、空間またはケーブルなどの伝送媒体上で情報を搬送する伝搬する電磁波）を含まないという意味で非一時的である。媒体およびコンピュータ・コード（コードと呼ばれることも可能である）は、１つまたは複数の特定の目的のために設計され、構成された媒体およびコンピュータ・コードとすることができる。非一時的コンピュータ可読媒体の例は、ハード・ディスク、フロッピ・ディスク、および磁気テープなどの磁気記憶媒体と、コンパクト・ディスク／デジタル・ビデオ・ディスク（ＣＤ／ＤＶＤ）、コンパクト・ディスク読取専用メモリ（ＣＤ−ＲＯＭ）、およびホログラフィック・デバイスなどの光記憶媒体と、光ディスクなどの光磁気記憶媒体と、搬送波信号処理モジュールと、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、読取専用メモリ（ＲＯＭ）デバイス、およびランダム・アクセス・メモリ（ＲＡＭ）デバイスなど、プログラム・コードを記憶し、実行するように特に構成されたハードウェア・デバイスとを含むが、これに限定されない。本明細書で説明される他の実施形態は、たとえば本明細書で議論される命令および／またはコンピュータ・コードを含むことができるコンピュータ・プログラム製品に関する。

［１２２９］コンピュータ・コードの例は、マイクロコードまたはマイクロ命令、コンパイラによって作られるものなどの機械命令、ウェブ・サービスを作るのに使用されるコード、およびインタープリタを使用してコンピュータによって実行される高水準命令を含むファイルを含むが、これに限定されない。たとえば、実施形態は、命令型プログラミング言語（たとえば、Ｃ、Ｆｏｒｔｒａｎなど）、関数型プログラミング言語（Ｈａｓｋｅｌｌ、Ｅｒｌａｎｇなど）、論理型プログラミング言語（たとえば、Ｐｒｏｌｏｇ）、オブジェクト指向プログラミング言語（たとえば、Ｊａｖａ、Ｃ＋＋など）、または他の適切なプログラミング言語および／または開発ツールを使用して実施され得る。コンピュータ・コードの追加の例は、制御信号、暗号化されたコード、および圧縮されたコードを含むが、これに限定されない。

［１２３０］様々な実施形態が上で説明されたが、それらが、限定ではなく例としてのみ提示され、形態および詳細における様々な変更が行われ得ることを理解されたい。本明細書で説明される装置および／または方法のどの部分もが、相互に排他的な組合せを除いて、任意の組合せで組み合わされ得る。本明細書で説明される実施形態は、説明される異なる実施形態の機能、構成要素、および／または特徴の様々な組合せおよび／または副組合せを含むことができる。

Claims

複数の計算デバイスに動作可能に結合されたネットワークを介して分散データベースを実施する前記複数の計算デバイス内に含まれるように構成された計算デバイスにある前記分散データベースのインスタンスに関連するメモリであって、
前記複数の計算デバイスは、
前記分散データベースに関連するイベント同意プロトコルの第１の構成に関連する、メモリと、
前記メモリに動作可能に結合されたプロセッサと、
を含む装置であって、
前記プロセッサは、
前記複数の計算デバイスからの計算デバイスの集合から、イベントの集合であって、イベントの前記集合からの各イベントは、（１）トランザクションの集合と（２）受信されたラウンド番号とに関連する、イベントの集合を受信し、
イベントの前記集合からの各イベントの順序を
（１）前記イベントに関連する前記受信されたラウンド番号が前記分散データベースの前記インスタンスによって識別された受信されたラウンド番号しきい値を超えないときには、前記イベント同意プロトコルの前記第１の構成に、
（２）前記イベントに関連する前記受信されたラウンド番号が前記受信されたラウンド番号しきい値を超えるときには、前記イベント同意プロトコルの第２の構成に
基づいて判定し、
イベントの前記集合からの各イベントの判定された前記順序に基づいて、前記分散データベースの前記インスタンスに関連する現在の状態を判定し、
前記現在の状態に関連するハッシュ値であって、第１の計算デバイスに関連する秘密鍵を用いてデジタル署名されたハッシュ値に基づいて、前記分散データベースの前記インスタンスに関連する署名付き状態を生成し、
前記署名付き状態を示すトランザクションを含むイベントを前記分散データベースの前記インスタンスにポストするために信号を送る
ように構成される、装置。
前記計算デバイスは、第１の計算デバイスであり、
前記複数の計算デバイスは、第１の時間期間中に前記分散データベースを実施する第１の複数の計算デバイスであり、
前記受信されたラウンド番号しきい値は、第２の複数の計算デバイスを定義するために前記第１の複数の計算デバイスに第２の計算デバイスを追加するトランザクションを含むイベントの受信されたラウンドに基づいて定義される、
請求項１に記載の装置。
前記計算デバイスは、第１の計算デバイスであり、
前記複数の計算デバイスは、第１の時間期間中に前記分散データベースを実施する第１の複数の計算デバイスであり、
前記受信されたラウンド番号しきい値は、第２の複数の計算デバイスを定義するために前記第１の複数の計算デバイスから第２の計算デバイスを除去するトランザクションを含むイベントの受信されたラウンド番号に基づいて定義される、
請求項１に記載の装置。
前記計算デバイスは、前記複数の計算デバイスからの第１の計算デバイスであり、
前記複数の計算デバイスからの各計算デバイスは、前記イベント同意プロトコル内で使用されるステーク値に論理的に関係付けられ、
前記受信されたラウンド番号しきい値は、前記複数の計算デバイスからの第２の計算デバイスに論理的に関係付けられた前記ステーク値を変更するトランザクションを含むイベントの受信されたラウンド番号に基づいて定義される、
請求項１に記載の装置。
前記受信されたラウンド番号しきい値は、第１の受信されたラウンド番号しきい値であり、
前記現在の状態は、前記分散データベースの前記インスタンスに関連する第１の状態であり、
前記プロセッサは、前記分散データベースの前記インスタンスの前記第１の状態を更新するトランザクションを含むイベントの前記集合からのイベントの受信されたラウンド番号に対応する第２の受信されたラウンド番号しきい値であって、前記第２の受信されたラウンド番号しきい値は、前記イベント同意プロトコルの第３の構成に関連し、前記第２の受信されたラウンド番号しきい値は、前記第１の受信されたラウンド番号しきい値より大きい、第２の受信されたラウンド番号しきい値を定義するようにさらに構成され、
前記プロセッサは、イベントの前記集合からの各イベントの前記順序を、
前記イベントに関連する前記受信されたラウンド番号が、前記第２の受信されたラウンド番号しきい値を超え、前記第２の受信されたラウンド番号しきい値を超えないときには、前記イベント合意プロトコルの前記第２の構成に、
前記イベントに関連する前記受信されたラウンド番号が、前記第２の受信されたラウンド番号しきい値を超えるときには、前記イベント合意プロトコルの前記第３の構成に
基づいて判定するように構成される、
請求項１に記載の装置。
前記プロセッサは、イベントの前記集合からの各イベントに関連するトランザクションの前記集合を、トランザクションの前記集合がそのイベント内で指定される順序に対応するサブオーダで実行することによって、前記分散データベースの前記インスタンスに関連する前記現在の状態を判定するように構成される、
請求項１に記載の装置。
前記計算デバイスは、前記複数の計算デバイスからの第１の計算デバイスであり、
前記受信されたラウンド番号しきい値は、前記イベント同意プロトコルに関連するソフトウェア変更を含むイベントの受信されたラウンド番号に基づいて定義される、
請求項１に記載の装置。
複数の計算デバイスに動作可能に結合されたネットワークを介して分散データベースを実施する前記複数の計算デバイス内に含まれるように構成された第１の計算デバイスにある前記分散データベースのインスタンスに関連するメモリと、
前記メモリに動作可能に結合されたプロセッサと、
を含む装置であって、
前記プロセッサは、
前記複数の計算デバイスからの第２の計算デバイスから、イベントであって、前記イベントは、親イベントの集合に関連するバイトのシーケンスであり、親イベントの前記集合からの各親イベントは、（１）ハッシュ値と（２）作成済みラウンド値とに関連する、イベントを受信し、
（１）親イベントの前記集合からの少なくとも１つの親イベントが、前記分散データベースの前記インスタンス内に識別子を有しておらず、かつ、
（２）前記少なくとも１つの親イベントが、第１の作成済みラウンドしきい値を超える作成済みラウンド値に関連するときに満足される第１の判断基準、または
（１）前記第１の判断基準が満足されず、かつ、
（２）親イベントの前記集合からの各親イベントが、第２の作成済みラウンドしきい値未満の作成済みラウンド値に関連する
ときに満足される第２の判断基準のうちの少なくとも１つが満足されるときに、イベントの順序の判定から受信されたイベントを除外し、
前記イベントが前記第１の判断基準または前記第２の判断基準に基づいて除外されなかったときに、前記分散データベースの前記インスタンス内に前記イベントを記憶する、
ように構成される、装置。
前記第１の作成済みラウンドしきい値は、前記分散データベースの前記インスタンスによって識別された現在の受信されたラウンド番号に基づく、
請求項８に記載の装置。
前記第２の作成済みラウンドしきい値は、前記分散データベースの前記インスタンスによって識別された現在の受信されたラウンド番号に基づく、
請求項８に記載の装置。
前記第１の作成済みラウンドしきい値は、前記第２の作成済みラウンドしきい値に対応する、
請求項８に記載の装置。
前記第１の作成済みラウンドしきい値は、前記第２の作成済みラウンドしきい値とは異なる、
請求項８に記載の装置。
前記受信されたイベントは、トランザクションの集合を含み、前記受信されたイベントは、第１の時刻のイベントの前記順序の前記判定から除外され、
トランザクションの前記集合は、前記第１の時刻の前の第２の時刻に実行される、
請求項８に記載の装置。
複数の計算デバイスに動作可能に結合されたネットワークを介して分散データベースを実施する前記複数の計算デバイス内に含まれるように構成された第１の計算デバイスにある前記分散データベースのインスタンスに関連するメモリと、
前記メモリに動作可能に結合されたプロセッサと
を含む装置であって、
前記プロセッサは、
前記複数の計算デバイスからの第２の計算デバイスによって定義されるイベントの群であって、イベントの前記群からの各イベントは、（１）シーケンス値と（２）トランザクションの順序集合とに関連するバイトのシーケンスを含む、イベントの群からのイベントの第１の集合の表示を前記メモリ内に記憶し、
同期化要求であって、前記同期化要求は、第１の識別子および第２の識別子を含み、前記第１の識別子は、イベントの前記第１の集合からの各残りのイベントに関連する前記シーケンス値未満のシーケンス値に関連するイベントの前記第１の集合からのイベントを識別し、前記第２の識別子は、イベントの前記第１の集合からの各残りのイベントに関連する前記シーケンス値を超えるシーケンス値に関連するイベントの前記第１の集合からのイベントを識別し、同期化要求を前記複数の計算デバイスからの第３の計算デバイスに送り、
前記同期化要求に応答して、前記第３の計算デバイスから、前記第２の計算デバイスによって定義されたイベントの前記群からのイベントの第２の集合を受信し、
イベントの前記第２の集合からの各イベントは、イベントの前記第１の集合には含まれない、イベントの前記第２の集合の表示を前記メモリ内に記憶し、
（１）イベント同意プロトコルと（２）イベントの前記第１の集合と（３）イベントの前記第２の集合とに基づいて、前記分散データベースの前記インスタンスの現在の状態を判定し、
前記現在の状態に関連するハッシュ値であって、前記ハッシュ値は、前記第１の計算デバイスに関連する秘密鍵を用いてデジタル署名される、ハッシュ値に基づいて、前記分散データベースの前記インスタンスの署名付き状態を生成し、
前記署名付き状態を示すトランザクションを含むイベントを前記分散データベースの前記インスタンスにポストするために信号を送り、
前記複数の計算デバイスからの計算デバイスの集合から、前記署名付き状態を示す前記トランザクションを含む前記イベントに関連する合意の表示を受信し、
前記メモリから、合意の前記表示に基づいて、イベントの前記第１の集合の前記表示およびイベントの前記第２の集合の前記表示を除去する、
ように構成される、装置。
前記プロセッサは、前記署名付き状態に関連し、前記複数の計算デバイスからの計算デバイスの前記集合に関連するデジタル署名の個数が署名しきい値に達したとの判定に基づいて合意の前記表示を受信するように構成される、
請求項１４に記載の装置。
前記現在の状態は、第１のラウンド番号に関連する第１の状態であり、前記プロセッサは、第１の時刻に前記第１の状態を生成するように構成され、
前記プロセッサは、前記第１の時刻の後の第２の時刻の、前記第１のラウンド番号を超える第２のラウンド番号に関連する前記分散データベースの前記インスタンスの第２の状態を生成する、
ようにさらに構成される、
請求項１４に記載の装置。
前記現在の状態は、イベントの第３の集合の同意順序に基づいてソートされた複数のトランザクションの実行から生成された前記分散データベースの前記インスタンスの状態に対応し、
イベントの前記第３の集合からの各イベントは、前記複数のトランザクションからのトランザクションの順序集合に関連し、イベントの前記第３の集合は、イベントの前記第１の集合およびイベントの前記第２の集合を含む、
請求項１４に記載の装置。