JP2021529378A - ブロックチェーンの分散台帳を実装する分散調整エンジンベースの取引方法、装置、及びシステム - Google Patents

Abstract

オンライン取引を実装する分散システムは、複数のサーバノードを備え得、該複数のサーバノードの各サーバノードは、オンライン取引の顧客から取引トランザクション提案を、コンピュータネットワーク上で受信するように構成され、各サーバノードは、完了した取引トランザクションのブロックチェーンの分散台帳のコピーを記憶するように構成される。分散調整エンジンは、コンピュータネットワーク上で、複数のサーバノードに結合され得、複数のサーバノードから複数の取引トランザクション提案を受信し得る。分散調整エンジンは、複数の取引トランザクション提案についてコンセンサスを達成して、それに応じて、コンセンサスに到達した複数の取引トランザクション提案を含む、合意済み取引トランザクション提案の順序付けを生成するように更に構成され得る。合意済み取引トランザクション提案のこの順序付けは、各サーバノードに同様に提供され、取引トランザクションを実行すべき、及び分散台帳の該取引トランザクションのコピーを更新すべき順序を特定する。合意済み取引トランザクション提案の順序付けは、元の取引トランザクション提案のノードサーバでの局所的な順序付けに従うように、任意に再順序付けされ、各サーバノードに同様に提供され得る。

Description

本明細書で開示する実施形態の分野は、分散システムを含む。特に、実施形態は、例えば、分散調整エンジンのインスタンスを使用して、インターネットを含み得る広域ネットワーク（ＷＡＮ：Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）上でオンライン取引を実装する分散システム（及び該システムによって可能になる機能）について作成される。また、実施形態は、ＷＡＮ上のかかる分散システムにおいて、分散及び／又は複製台帳の一貫性を維持する方法、装置、及びシステムについても作成される。他の実施形態は、分散台帳又はブロックチェーン技術を使用して安全な市場又は取引を実装するための方法及びシステムを含む。

図１は、一実施形態に従い構成されたシステムのブロック図である。

図２は、一実施形態による取引の態様を説明するブロック図である。

図３は、一実施形態による、取引トランザクション提案の大域的に順序付けられたシーケンスを生成する際に、局所的なシーケンス番号を尊重するコンピュータ実装方法の態様を説明するブロック図である。

図４は、一実施形態による取引の安全性及び暗号化の態様を説明するダイヤグラムである。

図５は、一実施形態によるコンピュータ実装方法のフローチャートである。

図６は、本明細書で図示し、記載した実施形態を遂行し得る演算装置のブロック図である。
詳細な説明
定義

分散システム：分散システムは、空間的に分離され得、且つメッセージ又はイベントの交換を通して互いに通信し得る個別プロセスの集合を備える。

合意：合意は、提案者によって生成され、学習者に配信される可能性がある複数の提案イベント中の選択された１つである。

合意の大域的シーケンス：一実施形態によると、買値又は売値の提案は、少なくとも大部分の受諾者に対して提出され、該受諾者によって合意され、合意の大域的シーケンスで配信される。合意の大域的シーケンスを受信したサーバノードは、次に、合意の大域的シーケンスによって特定された順序で基本的なトランザクションを実行し、それに従って複製台帳のコピーを更新し得、それによって、確実に、複製台帳の全コピーを同じ順序で更新できる。

分散合意／調整エンジン（ＤＣｏｎＥ：Ｄｉｓｔｒｉｂｕｔｅｄ ａｇｒｅｅｍｅｎｔ／ｃｏ−ｏｒｄｉｎａｔｉｏｎ ｅｎｇｉｎｅ）：一実施形態では、合意又は調整エンジンに、Ｐａｘｏｓコンセンサスプロトコルの新規なプロダクショングレード実装を通して、合意済みトランザクションの順序付けられた大域的シーケンスを生成することを要求する。例示のＤＣｏｎＥについては、本発明の譲受人に譲渡され、同時係属中の、２００８年２月１３日に出願された米国特許出願第１２／０６９，９８６号に記載されており、同出願は、全体として参照により本明細書に援用される。ＤＣｏｎＥは、フォールトトレラントで、連続的に利用可能で、決定論的に複製される状態機械である。ＤＣｏｎＥは、提案者によって生成されたイベントを収集し、該イベントを、受諾者の助けを借りて順序付けされた大域的シーケンスに編成し、該イベントをそのシーケンスで学習者に配信することによって、作動する。学習者は、配信されたイベントの順序付けられたシーケンスを取扱うことによって、ビジネスロジック（トランザクション、例えば、本取引又は市場の、を実装する）を実装する。ＤＣｏｎＥは、各トランザクション提案イベント（買値又は売値）を、少なくとも一度、合意済みの取引トランザクション提案の同じ順序の大域的シーケンスで、各学習者ノードに配信することを保証する。

非ブロッキング：本明細書では、用語「非ブロッキング」とは、１組のプロセスを、完全に又は部分的に利用可能な状態に保ちつつ、その組に対して変更を行える能力のことを言う。

提案者：一実施形態によると、提案者とは、取引トランザクションを提示するように（即ち、買値又は売値の提案をするように）構成され、該提示が可能であるプロセスである。

受諾者：一実施形態によると、受諾者とは、提案者が行った提案の順序についての決定に参加するように構成されるプロセスである。一実施形態によると、大部分の受諾者が、提案が合意の大域的シーケンスにおいて特定の順位になると判断した時にのみ、合意（例えば、合意済み提案）となる。受諾者は、一実施形態によると、合意の順序についての決定に参加だけするように構成され得、合意の基本的な内容について推論しない／関心を持たない（本明細書で記載したように、合意の値は、ＤＣｏｎＥには不明瞭である）。受諾者は、アプリケーション非依存エンティティとして構成され得る。

学習者：一実施形態によると、学習者は、提案者と受諾者との間で行われた合意について学習し、合意を、決定論的順序で、それらの出力提案シーケンスを通して、アプリケーションに適用する。一実施形態では、合意のアイデンティティは、各複製状態機械に対して、合意のシーケンスを持続的に記録可能にする持続的な記憶装置であるように、提供される。各提案は、特定のメンバシップがある各学習者に少なくとも一度配信されるよう保証される。
分散調整エンジン（ＤＣｏｎＥ）

一実施形態によると、ＤＣｏｎＥは、Ｐａｘｏｓアルゴリズムの拡張企業版を実装する。Ｐａｘｏｓアルゴリズム下では、複製状態機械は、分散システム−この場合、分散オンライン取引において、各ノードにインストールされる。その結果、複製状態機械は、ピアとして機能して、−必ずしも同時ではないが−、確実に、あらゆるノードで、同じ取引順序にする取引トランザクション管理に対する協調的アプローチを提供する。Ｐａｘｏｓアルゴリズムを実装するサーバノードにある複製状態機械は、任意の３つの役割：（１）提案者；（２）受諾者；及び（３）学習者の１つを果たすことができる。Ｐａｘｏｓアルゴリズムには、コンセンサスに到達するプロセス中に繰り返され得る３つの段階がある：（１）調整者又は提案者となるノードを選択する段階；（２）次に、提案を受諾する又は拒絶する学習者の役割を担うそのピアに、トランザクション提案を一斉通信（ｂｒｏａｄｃａｓｔ）する段階；及び（３）大部分のノードが、提案者を承認し、その提案を受諾すると、受諾となり、コンセンサスに到達可能になる段階。調整者の役割を担う複製状態機械は、次に、コミットメッセージを一斉通信して、トランザクションを進めるようそのピア全てに通知する。

複数のノードが同じ提案に対して調整者の役割を果たそうとするシナリオを避けるために、Ｐａｘｏｓは、連続する調整者ノードに順序付けを割当て、提案番号に対して合意される値を選択する際に、各調整者の選択を制限する。これを支援するために、各ノードは、把握した最新の合意提案のシーケンス番号を追跡記録する。ノードが提案を発行するとき（この場合、買値又は売値）、該ノードは、該ノードが認識している最後の値より高い値を有する提案に対してシーケンス番号を生成し、該番号を他のノードに一斉通知する。大部分の他のノードが、より高いシーケンス番号を把握していないことを示す応答をするならば、そのノードは、その提案に対する調整者又はリーダの役割を果たすことが許可される。この時点で、他の調整者は、現提案についてコンセンサスに到達するまで、進めない。提案者のシーケンス番号は、同時に調整者になろうとする他のノードによって使用できず、今後の全提案は、今後のトランザクションに関するコンセンサスを達成するのに、より高いシーケンス番号を使用しなければならない。
ＤＣｏｎＥを用いたコンセンサスの達成

分散トランザクション処理に対するＤＣｏｎＥのアプローチを理解するために、以下で、アクティブ／アクティブ複製能力を支援する各ＤＣｏｎＥインスタンスのコア構成要素について詳述する：提案マネージャ、局所的シーケンサ、合意マネージャ、及び大域的シーケンサ。買値又は売値のトランザクションが、任意のノードにある顧客によって、処理のために取引所に提出されると、ＤＣｏｎＥの局所的インスタンスの提案マネージャ構成要素は、トランザクションデータを含む、トランザクション用提案を生成する。かかるトランザクションデータは、少なくとも買い手又は売り手のＩＤ、売買量及び値段を含み得る。次に、ＤＣｏｎＥインスタンスは、局所的シーケンス番号（ＬＳＮ：ｌｏｃａｌ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を提案に割当てる。ＬＳＮは、トランザクションが、その場所にある他の全トランザクションに関して提出された順序を反映する。ＬＳＮは、連続した番号である必要はなく、単に一意であればよい。その後、局所的シーケンサは、割当てられた局所的シーケンス番号と共に提案を、その提案ログに保存する。ＤＣｏｎＥの局所的インスタンスが、後述する合意プロセス中に、提案をそのピアに提出できる前に、ネットワーク又はサーバの故障が発生した場合、回復後に、その提案を再提出する。

次に、ＤＣｏｎＥの合意マネージャは、合意番号を決定し、該合意番号は、局所的ＤＣｏｎＥインスタンスが他のノードにあるそのピアに提出するであろう提案のための提案された大域的シーケンス番号（ＧＳＮ：ｇｌｏｂａｌ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を表す。Ｐａｘｏｓに従い、この合意番号を、全てのノードによって受諾された最後の提案のＧＳＮの単なる増分にする。その後、この合意番号は、全てのノードに亘り取引トランザクションの順序付けについてコンセンサスを得るのに使用され、それにより単一コピー等価性（ｏｎｅ−ｃｏｐｙ ｅｑｕｉｖａｌｅｎｃｅ）が維持されるようにする。その後、合意番号が付された提案は、合意ログに書き込まれる。各ＤＣｏｎＥインスタンスの合意ログ又は複製台帳は、完了した合意が発生したサーバノードに関わらず、少なくとも全ての完了した合意を含む。ネットワーク故障の場合、合意ログは、分散システムにおける他のノードへの接続を喪失する前に、ノードが停止した場所を示し、ＤＣｏｎＥの自動化された回復プロセス中に、それを役立てる。合意ログと提案ログの両方が回復プロセスにおいて果たす役割について、以下で説明する。

その後、合意プロトコルは、局所的ＤＣｏｎＥインスタンスの合意マネージャによって開始され、提案は、そのピアに提出される。ＤＣｏｎＥインスタンスのピアのクォーラム（ｑｕｏｒｕｍ）が、提案について合意に達すると、合意番号は、大域的なトランザクションの順序付けがその時点で達成されたとして、全てのノードに亘りＧＳＮとして使用される。このクォーラムの概念により、ＤＣｏｎＥは、全てのノードが利用可能である又は合意する必要なく、合意に到達可能になる。クォーラムの概念は、その耐障害性と共に、ＤＣｏｎＥの性能の主要な要素である。また、以下で、クォーラム概念について説明する。

合意が、競合する提案によって先買される場合、合意マネージャは、新たな合意番号で合意に到達するよう繰り返し試行する。合意が再試行される度に、新たな合意番号を有するエントリが、合意ログに作成される。クォーラムによって合意に到達されると、局所的アプリケーションノードは、合意済み提案をその大域的シーケンスにおいてエンキューする。この時点で、局所的ＤＣｏｎＥインスタンスは、トランザクションを、処理のための各ロッキングスケジューラに、合意された大域的シーケンス番号順に、受け渡す。トランザクションの実行を完了するのに、提案が発生したＤＣｏｎＥインスタンスは、いかなる他のノードも待たない；合意に到達するだけを待って、ユーザがＬＡＮ速度性能を経験可能にする点に注目することは、重要である。
局所的シーケンスの保存

ＤＣｏｎＥが、パフォーマンスの理由で並行合意に対応するため、故障状態でもクォーラムが合意に到達可能になる。即ち、別のノードの先に提出され、まだ合意済みでない取引トランザクション提案の後に提出された取引トランザクション提案について合意に到達できる。

ＤＣｏｎＥが、複数のサーバノードから取引トランザクション提案を取得し、一意の大域的順序と該提案を照合し、他のあらゆるサーバノードにアクセス可能にさせることを想起されたい。また、ＡｕＸ等のアプリケーションが、ＤＣｏｎＥ上に構築されている点も考慮されたい。時には、所与のサーバノードに関して、先着順又は先入れ先出し（ＦＩＦＯ：Ｆｉｒｓｔ−ｉｎ−Ｆｉｒｓｔ−Ｏｕｔ）を実装し、取引トランザクション提案の取扱い時に到着時刻に基づいて処理し、確実に該提案を同じ順序で出力することが、望ましい。この種の順序付けは、例えば、公平方針又は因果順序制約によって強制され得、公平方針又は因果順序制約は、一実施形態によると、複数のサーバノードによって発行された全ての取引トランザクション提案についてコンセンサスを獲得する、及びコンセンサスに到達することによって満たされる２つの必要条件である。例えば、Ｐ_０を、顧客Ｃ用の口座を開設するという提案とし、Ｐ_ｔを、顧客Ｃからの売買とする。勿論、取引は、顧客Ｃの売買Ｐ_ｔが行われる前に、顧客Ｃの口座が開設されるような実行順で制約されるべきである；つまり、出力側の実行順は、Ｐ_０がＰ_ｔの前に現れるように制約されるべきである。残念ながら、ＣがＰ_０とＰ_ｔを２つの異なるノードに提出するならば、この方針に対する解決策は無くなる。しかしながら、Ｐ_０とＰ_ｔが同じノードに提出される場合、一実施形態は、後述する、前処理と後処理ステップを加えることによって、この制約を満足する。大域的に順序付けされたシーケンスに、トランザクション提案の局所的シーケンスを保存するのが必要な別の実施例は、金融部門において存在する。実際に、顧客が小切手を預金し、小切手の一部を現金の形で引出す銀行業務シナリオについて考察してみる。これらのトランザクションも、その順序、即ち、最初に、預金Ｐ_０、その後引出しＰ_ｔという順序で起きるはずである。上述したように、ＣがＰ_０とＰ_ｔを２つの異なるノードに提出するならば、この方針に対する解決策は無い。前処理ステップは、提案シーケンスに注釈を付けるのみであり、従って、正確さに影響を全く及ぼさない。その一方で、後処理は、ＤＣｏｎＥの出力を再配列する。しかしながら、後処理は、決定論的な方法でそれを行う。ＤＣｏｎＥの結果生じる出力は、全サーバノードに亘り同じであるという、ＤＣｏｎＥの特性のため、後処理ステップからの出力は、結果的に、全サーバノード上で、合意の同じシーケンスとなるだろう。

以下では、提案の提出の局所的シーケンスを保存しながら、ＤＣｏｎＥが、大域的トランザクションの順序付けを決定できるようになる一実施形態について説明する。サーバノードが、その最初の２つの取引トランザクション提案をＤＣｏｎＥに提出して、提案マネージャがＬＳＮ１とＬＳＮ２をそれぞれの取引トランザクション提案に割当てると仮定する。更に、ＧＳＮ１〜２５を有する合計２５の取引トランザクション提案が合意されており、全く介在する取引トランザクション提案が、他のサーバノードによって提出されていないと仮定する。更に、クォーラムは、ＬＳＮ１について合意に到達する前に、ＬＳＮ２について合意に到達したと仮定する。局所的シーケンスがアプリケーションにとって重要でなければ、ＬＳＮ２は、合意番号及びＧＳＮ２６を有し、ＬＳＮ１は、合意番号及びＧＳＮ２７を有するであろう。その後、提案は、全てのサーバノードでその順序で書き込まれるであろう。要件が、確実に、局所的シーケンスを、提案がどこで発生するかにかかわらず全てのノードで保存することである場合、一実施形態は、ＬＳＮ、この場合ＧＳＮで終端するかどうか分からない合意番号、及び提案が発生したＤＣｏｎＥインスタンスに対する大域的に一意の識別子を表す提案者ｉｄの組合せを局所的シーケンス順序を保存する大域的シーケンスを組み立てるために使用する。事実上、大域的シーケンスは、提案者ｉｄ中で、局所的シーケンス順序で分類され、各サーバノードにある、以下で言及するロッキングスケジューラに、送られる。一実施形態による局所的シーケンスを保存する別の方法は、以下で、図４に関して開示される。
ロッキングスケジューラ

ロッキングスケジューラは、ＤＣｏｎＥが合意済み取引トランザクション提案を、サーバノードそれぞれで実行する取引アプリケーションに送る各サーバノードにある。ロッキングスケジューラは、分散ロックマネージャではなく、データベーススケジューラのように振る舞う。用語「ロッキングスケジューラ」は、同時制御用取引アプリケーションによって特定されるロックに依存し、それにより多数の相反しないトランザクションを並行して処理できるようにする点に由来する。ロッキングスケジューラは、大域的順序にとらわれない。ロッキングスケジューラが各サイトにある基本的な取引アプリケーションにトランザクションを提出する順序は、そのサーバノードにあるその各ＤＣｏｎＥインスタンスからロッキングスケジューラに送られた大域的に順序化されたイベントの局所的キュー（ＧＳＮキュー）によって進められる（ｄｒｉｖｅｎ）。これにより、各サーバノードにある局所的ロッキングスケジューラが、大域的状態に関する知識を全く持たずに単一コピー等価性を完全に達成可能になる。直接ＤＣｏｎＥではなく、基本的なＡｕＸアプリケーションとインタフェースするのは、ロッキングスケジューラである。
パフォーマンスとスケーラビリティの達成

ＤＣｏｎＥは、Ｐａｘｏｓアルゴリズムの機能を大幅に拡張し、それによって大規模にパフォーマンスの増強を可能にする。かかる拡張機能は、かかる拡張機能によって包含された少数領域以外を識別するために、クォーラム、並行合意処理（ｈａｎｄｌｉｎｇ）、バックオフ及び衝突回避、動的グループ展開、分散ゴミ集め、卓越した公平な提案用ラウンド数、及び弱い予約を含む。
クォーラム

ＤＣｏｎＥによって使用されるクォーラム概念により、パフォーマンスを最適化可能になり、ネットワークやサーバの故障の影響を、サーバノードに亘る取引及び売買活動の顧客の分散に基づいて、最小化可能になる。利用可能なクォーラム構成オプションは、多数決、シングルトン（ｓｉｎｇｌｅｔｏｎ）、全員一致を含む。シングルトンや全員一致のコンセンサスも可能であるが、取引は、多数決のクォーラムによって達成されるコンセンサスでも機能するであろうと予想される。多数決のクォーラムでは、サーバノードの大部分が、任意の取引トランザクション提案に応答する必要がある。また、ＤＣｏｎＥは、分散システムにおいてサーバノードが偶数ある場合、同点決着者としての役割を果たせる卓越したノードの概念にも対応する。シングルトンのクォーラムでは、１つのノードだけが、取引トランザクション提案に応答する必要がある。この構成下でシングルトンクォーラムになるよう選択されるサーバノードは、最大数の顧客と売買活動のレベルを有するサーバノードであり得る。この利点は、広域ネットワーク（ＷＡＮ）トラフィックが、合意プロセス中に、最高トランザクション量を有するサーバノードで、全く生成されないことである。合意は、クォーラムノードで局所的ＤＣｏｎＥインスタンスによって完全に取扱われる。他のサーバノードは、自分の取引トランザクション提案を提出して、シングルトンのクォーラムノードから合意を得るが、典型的には、該サーバノードの取引トランザクション提案に合意するのに、該サーバノードが各局所的ロッキングスケジューラに提案を引渡す前に、該サーバノードの完全な実行ではなく、指定されたシングルトンのサーバノードを必要とするだけであるため、高速パフォーマンスを経験する。全員一致のクォーラムは、全てのサーバノードが応答する必要があり、本質的に最も効率的でない構成であり、最もＷＡＮトラフィックを生成する構成である。

また、ＤＣｏｎＥは、フォローザサンモデルに基づいて、一領域から別の領域へとクォーラムの交替に対応する。これにより、大域的に分散されたシステムにおいて、各サイトでの標準労働時間に基づいてパフォーマンスが最適化可能になる。加えて、クォーラムアプローチは、ＤＣｏｎＥの自動化された回復機能と共に働いて、分散システム上での、ネットワークの故障やサーバのクラッシュの影響を最小化する。
並行合意

Ｐａｘｏｓアルゴリズムは、一度に一提案について合意に到達可能にするのみである。これには、高トランザクション量環境においてパフォーマンスを減速させるという明白な作用がある。ＤＣｏｎＥは、複数の取引トランザクション提案者からの複数の取引トランザクション提案を、むしろ提案毎ベースで、サーバノードの全数又はクォーラムによる合意への到達を待つより、同時に進行可能にする。
バックオフ及び衝突回避

ＤＣｏｎＥは、提案者がピアによって繰り返し先買されるのを回避するのに、バックオフメカニズムを提供する。従来の複製状態機械では、先買された提案者が、先買者よりも高い合意番号で新たなラウンドを直ぐに開始できる。このアプローチでは、合意プロトコルが、長期間パフォーマンスに打撃を与え、パフォーマンスを著しく低下させる原因となることがある。ＤＣｏｎＥでは、ラウンドが先買されると、提案を開始したＤＣｏｎＥインスタンスは、バックオフ遅延の持続時間を計算する。その後、提案者は、次のラウンドを開始する前に、この持続時間中待機する。ＤＣｏｎＥは、非切替型イーサネットに対して、キャリア検知多重アクセス／衝突検出（ＣＳＭＡ／ＣＤ）プロトコルと同様のアプローチを、使用する。
自動バックアップ及び回復

ＤＣｏｎＥのアクティブ／アクティブ複製能力は、デフォルトで、あらゆるサーバノードをあらゆるもう一方のミラーにすることによって、連続的なホットバックアップを配信する。これは、サーバノードが、ネットワーク又はサーバの不良により遅れた際に、ＷＡＮ、又はＬＡＮ上で自動回復を提供するために活用される。人間の介入は不要である。取引においてサーバノードが、そのピアとの通信が途絶えているものの、依然としてその場所で取引顧客に対して使用可能である場合、それら取引顧客は、まだ取引に対する読込みアクセスはできるだろうが、合意プロセスを進行できないため、取引トランザクションは開始できないだろう。これは、サーバノードがそのピアと同期しなくなり、全サーバノードに亘り単一コピー等価性の要件を侵害する結果を招く恐れがあるスプリットブレインシナリオが発生するのを防止する。しかしながら、取引トランザクション提案は、クォーラムがまだ有効であれば、残りのサーバノードで依然として提出できる。これにより、分散システム上での、ネットワーク故障やサーバ不具合の影響を最小化できる。不具合のサーバノードがオンラインに復帰すると、そのＤＣｏｎＥインスタンスは、オフライン中にそのピアによって合意された取引トランザクション提案全てに自動的に追着く。これは、合意ログを使用して、達成される。合意ログは、故障が起こる前に、サーバノードで完了された最後の取引トランザクションを含む。回復プロセスが始まると、サーバノードのＤＣｏｎＥインスタンスは、そのピアからの合意ログに記録された最後の取引トランザクション後の全取引トランザクションを要求する。更に、合意プロセスを完了しなかった提案ログに残されたいかなる取引トランザクション提案も、完全に追着くと、局所的ＤＣｏｎＥインスタンスによって自動的に再提出される。これは、故障が、分散システムにおけるサーバノードに亘り、任意の取引トランザクション提案について、合意に到達する前又は後に発生するかに関わらず、全くデータが喪失されないことを意味する。

更に、ＤＣｏｎＥの自動回復能力により、ＷＡＮではなく、ＬＡＮ上のみで作動し、回復を達成するために管理者の介入を必要とするディスクミラーリングソリューションの必要性がなくなる。その結果、これらのソリューションにより、ダウン時間が延長したり、人為ミスによりデータが損失したりする危険性を招く可能性がある。また、最後に、ＤＣｏｎＥの自動回復機能は、ユーザアクセスを中断せずにメンテナンスのために、サーバをオフラインにできるが、これは、取引顧客が、彼らのサーバがオフライン中に別のサイトにあるサーバノードにリダイレクトできるからである。これで、世界的に分散された環境において、完全に２４時間無休で動作可能になる。

説明目的で、本明細書に記載されるのは、ＤＣｏｎＥの実装に基づくブロックチェーン又は分散台帳を実装する取引又は市場の例である。ブロックチェーンは、分散情報リポジトリに対して意図的に変更できる分散台帳である。取引や市場に関連して本明細書で記載するような、許可型ブロックチェーン又は分散台帳は、トランザクションにアクセスして、開始するために特別な許可を必要とすることがある点で、パブリックブロックチェーンと異なる。かかるブロックチェーンの本質的な構成では、参加者のトランザクション（この場合、買値及び売値）を制御し、それらの役割（買い手、売り手）を定義する。また、取引又は市場は、セキュリティ、監査、及び課税目的で、ネットワーク上で各取引顧客のアイデンティティを維持できる。また、許可型分散ブロックチェーンは、ゲーム理論的なコンセンサスの代わりにアルゴリズム的コンセンサスを使用できるため、パブリックブロックチェーンと区別し得る。本明細書に開示した許可型ブロックチェーンベースの分散取引は、かかるアルゴリズムのコンセンサスのためのプラットホームとしてＤＣｏｎＥを利用する。ユースケースに応じて、各種暗号化手法を使用して、信頼関係性に対処し得る。本明細書で言及したかかる分散取引の一実施例は、本明細書でＡｕＸと呼ぶ、オンライン金取引である。しかしながら、本明細書に記載したＡｕＸ金取引は、分散型の耐障害性で災害に強い本オンライン取引又は市場に関する説明に資する例示的な一実装にすぎず、他の実装も、皆、当業者が認めるように、異なるニーズや機能性に役立つであろう点に、注意すべきである。

実際に、本明細書に記載し、図示した取引は、フォールトトレラントで、安全で、高性能な分散アプリケーションをＤＣｏｎＥ上に構築できる容易さを証明するもので、ＡｕＸは、代表的な使用例にすぎない。一実施形態は、様々な、地理的に分散される可能性があるサーバノードからの取引トランザクション提案（例えば、買値又は売値）を受諾し、コンセンサスを獲得し、合意済み取引トランザクション提案を、その後あらゆるサーバノードに利用可能にする順序付けされた大域的シーケンスに照合するように構成されたＤＣｏｎＥインスタンスを含む。一実施形態では、生成される順序付けられた大域的シーケンスは、トランザクション提案がサーバノードの何れか１つに提示された局所的順序を尊重する。異なる分散サーバノード上で実行する同一のアプリケーションソフトウェアは、単独で取引トランザクション提案のこの順序付けられた大域的シーケンスを処理し、従って、複製された状態機械を維持する。ＤＣｏｎＥを使用するかかる取引又は市場に関する顕著な特徴は、トランザクション提案のかかる順序付けられた大域的シーケンスが、サーバノードの大部分を含むコンセンサスが常時機能する限り、生成され続け得る点である。

図１は、一実施形態による分散調整エンジン（ＤＣｏｎＥ）を使用して取引を実装する分散システムの略図である。一実施形態によると、（奇数が好ましい）複数（例えば、３、５、７…）のサーバノードが、コンピュータネットワーク上で、ＤＣｏｎＥ２０８によって、提供され、調整され得る。図１で示すように、例示目的のみの一実施形態は、３つのサーバノード１０２、１０４、１０６を備え得、各サーバノードは、ＤＣｏｎＥ１０８と結合される。一実施形態によると、ＤＣｏｎＥ１０８は、各ノード又はノードのクラスタ（互いに遠くに分離され得る）にあるエージェント又はインスタンスとして、該エージェント又はインスタンスが、ＬＡＮ等のネットワーク又はインターネット等のＷＡＮ上で互いに調整している状態で、構成され得る。しかしながら、参照や描写をし易くするために、ＤＣｏｎＥ１０８は、本明細書では、別々の、単一のエンティティであるとして示されている。一実施形態によると、サーバノード１０２、１０４又は１０６の１つで開始される分散台帳への更新は、ＤＣｏｎＥ１０８によって、一貫した方法で他のサーバノードに伝播される。この様に、顧客（例えば、取引における買い手や売り手等の）は、取引所と結合された全サーバノードに亘り分散される及び／又は複製される台帳に依存できる。分散台帳に関して本明細書で開示された複製方法は、高可用性のアクティブ／アクティブモデルを分散システムに提供し、取引の構成サーバノード間で負荷の平均化を可能にする。

ＤＣｏｎＥ１０８は、取引又は市場において発生する全トランザクションを記録する分散台帳への更新に関する大域的順序を決定するように構成され得る。分散台帳の全インスタンスは、同じ状態で開始されるため、また全サーバノードは、同じ決定論的順序で更新を適用させる（しかし、必ずしも、実施形態によっては、同時でなくてもよい）ため、分散台帳の複数のインスタンスの状態は、ノードに亘り、一貫性が保たれる（又は、一貫したものになる）。

一実施形態によると、図１に示したように、複数のサーバノード１０２、１０４又は１０６上の取引トランザクションの分散台帳への一貫した更新は、以下の通り実行され得る。（１）で示したように、サーバノードの１つ（この場合、サーバノード１０２）は、顧客から買値又は売値３、実際には、特定量の商品又はサービス（本明細書に記載したＡｕＸの場合、金）を売買する提案を、謹んで受信し、それにより、最終的に分散台帳への更新が発生する。同様に、この実施例では、サーバノード１０４は、買値又は売値１を受信し、サーバノード１０６は、取引の顧客から買値又は売値２を受信する。一実施形態によると、サーバノード１０２が、その台帳を、イベント（例えば、売買リクエスト）を買／売値３内にカプセル化した状態で、直ぐに更新し、サーバノード１０４が、その状態を、イベントを受信された買／売値１内にカプセル化した状態で、直ぐに更新し、サーバノード１０６が、その状態を、イベントを受信された買／売値２内にカプセル化した状態で、直ぐに更新し、その後、サーバノード１０２、１０４、１０６中の他のものに対するかかる更新を、伝播する代わりに、これら別個の提案された取引トランザクションは、提案としてＤＣｏｎＥ１０８に渡され、ＤＣｏｎＥ１０８は、これらを、本明細書に記載したように、受諾者ノードの大部分が、該提案について合意に到達した（合意は、いかなるコンセンサスプロトコルが実施されても、コンセンサスに到達される）後に、対応する合意として、サーバノード１０２、１０４、１０６に送り返す。

即ち、図１に示したように、買／売値３の受信に応答して、サーバノード１０２は、提案Ｐｒｏｐ３を、（２）で示したように、ＤＣｏｎＥ１０８に発行し得る。同様に、買／売値１の受信に応答して、サーバノード１０４は、提案Ｐｒｏｐ１を、（２）で示したように、ＤＣｏｎＥ１０８に発行し得、買／売値２の受信に応答して、サーバノード１０６は、提案Ｐｒｏｐ２を、また（２）で示したように、ＤＣｏｎＥ１０８に発行し得る。一実施形態によると、その後、ＤＣｏｎＥ１０８は、受諾者ノードの大部分のコンセンサスを通して合意を獲得し、（３）で示したように、合意済み取引トランザクション提案をシリアル化し、ＤＣｏｎＥ１０８が受信する提案を順序付け、（４）で示したように、順序付けされた合意（この場合、ＡＧＲ３、ＡＧＲ１及びＡＧＲ２として順序付けされる）の流れとして、合意済みのこれら提案を、サーバノード１０２、１０４、１０６へフィードバックする。順序付けされた合意ＡＧＲ３、ＡＧＲ１及びＡＧＲ２のシーケンスを受信すると、サーバノード１０２、１０４及び１０６は、その決定論的順序でこれらの合意を実装し、それに応じて、分散又は複製台帳を更新し、それによりサーバノード１０２、１０４、１０６に亘り一貫性が維持される（及び／又は一貫する）ようにする。この様に、（５）で提示したように、取引についてのトランザクションを詳述した分散又は複製台帳の状態を、サーバノードに亘り一貫性を失わずに、非同期で更新し得る。その後、これらの更新は、局所的永続的記憶装置１１０、１１２、１１４それぞれに、実行記録（ｊｏｕｒｎａｌ）トランザクションとして保存され得（しかし、保存される必要がない可能性もある）、該各局所的永続的記憶装置は、サーバノード１０２、１０４、１０６に結合される又はアクセス可能にされ得る（しかし、１１０、１１２及び１１４で点線で示したように、必要がない可能性もある）。その後、通知が、適宜、買値又は売値の取引トランザクションを提出した顧客に、返信され得る。

従って、一実施形態によると、サーバノード１０２、１０４、１０６は、複製又は分散台帳のコピーにおいて、顧客の買値又は売値を直接記録しないが、むしろ該買値又は売値を、提案として、コンセンサスを通した合意、シリアル化及び順序付けのために、ＤＣｏｎＥ１０８にリダイレクトする。これらのサーバノードに記憶された分散及び／又は複製台帳への更新は、その後、合意の順序付けられた組として、ＤＣｏｎＥ１０８から及びＤＣｏｎＥ１０８によって発行される。これは、取引顧客（例えば、買い手又は売り手）が、最終的に実装される買又は売注文を発行すると、あらゆるサーバノード１０２、１０４、１０６が更新されることを保証し、それにより該更新は、クラスタにおける全サーバノードに透明性が高く、一貫して適用されるようになる。この様に、全トランザクションの順序付けされ、複製された台帳は、分散システムに亘り、複数のサーバノードそれぞれによって維持され得る。

そのために、ＤＣｏｎＥ１０８の重要な役割は、一実施形態によると、取引のサーバノードから受信された取引トランザクション提案を処理し、該提案を合意の大域的に順序付けられたシーケンスに変換することである。サーバノード（地理や時間帯に亘り広く分離され得る）は、その結果、その順序付けられたシーケンスから合意の基礎となるトランザクションを実装し得、それに応じて順序付けられた更新を、取引の全トランザクションを記録する分散又は複製台帳へ、適用し得る。合意は、一実施形態によると、大域的シーケンス番号（ＧＳＮ：Ｇｌｏｂａｌ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）に従い順序付けされ得、該ＧＳＮは、一意の単調に増加する数として、構成され得る。ＧＳＮは、当業者が認識し得るように、その他の方法でも、構成され得る。その後、ＧＳＮは、分散台帳を更新する際や、サーバノードに亘り該台帳の状態の一貫性を保つ際に、異なるサーバノードの進行を比較するのに使用され得る。例えば、サーバノード１０２が、サーバノード１０４によって処理されたばかりのＧＳＮ２より小さいＧＳＮ１と付番された合意を処理したところならば、サーバノード１０２によって記憶された台帳のインスタンスは、サーバノード１０４によって記憶された台帳のインスタンスより前の状態にあるということになる。

一実施形態によると、サーバノード複製状態機械に対する顧客読込み動作（例えば、過去のトランザクションを再検討する要求、様々な報告要求）は、ＤＣｏｎＥに、コンセンサスに到達することを求めず、書き込むだけである。一実施形態によると、ＤＣｏｎＥ１０８は、全サーバノード１０２、１０４、１０６の台帳のインスタンスが、常に全サーバノードで同じであると保証しない点に留意すべきである。むしろ、ＤＣｏｎＥ１０８は、各サーバノード１０２、１０４、１０６が、他の全サーバノードと同じ順序で各取引トランザクションについて一貫して学習するのを保証し、取引顧客は、この情報を見ることができる。この様に、ＤＣｏｎＥ１０８は、全てのサーバノード１０２、１０４、１０６に同様に供給されるイベントの大域的に順序付けられたシーケンスを生成して、逐次順序付けされた予測可能な更新を、分散及び／又は複製台帳に対して行わせるように構成される。次に、これにより確実に、取引イベントが、各サーバノードによって、同じ順序で使われ、その結果、分散及び／又は複製台帳の各インスタンスを、予測可能な耐タンパ性の決定論的な方法で、変化（ｅｖｏｌｖｅ）させる。

一実施形態によると、局所的永続的記憶装置１１０、１１２、１１４に記憶されたジャーナルへの更新が、実行され得る。しかしながら、サーバノード１０２、１０４、１０６によって記憶された台帳の一貫性は、かかるジャーナルの更新に依存せず、一実施形態によると、各永続的記憶装置（存在する場合）は、サーバノードに対して局所的であり、他のサーバノードとネットワーク上で共有されない。同様に、サーバノード１０２、１０４、１０６に亘り分散及び／又は複製台帳の一貫性を維持するのに、メモリ又はプロセッサリソース等の他のリソースを共有することに頼らない。

実施形態によると、取引の分散システムにおいて、好適な（最上の又は他の卓越した）サーバノードは存在しない。実際に、万が一１つ又は複数のサーバノードが不具合になった場合、又はメンテナンスのために（又は他の理由で）オフラインになる場合、他のアクティブなサーバノードが、アクセス時に全く中断せずに顧客の買値又は売値リクエストを扱うために利用可能となる。一実施形態によると、以下に記載するように、以前ダウンしたサーバノードがオンラインに戻るとすぐに、他のサーバノードのサーバで自動的に再同期する。かかる同期は、サーバノードがダウンした、又はオフラインになったために、ＤＣｏｎＥ１０８によって発行された全ての合意済み取引トランザクション提案を学習することを含み得る。全サーバノードの台帳が常に同期に維持される又は同期になり、それによって、デフォルトで連続したホットバックアップを提供できるため、スプリットブレイン状態とデータ喪失両方が排除される。フェイルオーバと回復の両方が、即座に且つ自動的に行われ、これは、人間が介在する必要性や管理者エラーの危険性も更に排除する。その上、サーバノード１０２、１０４、１０６の何れも、パッシブな又は待機サーバノードとして構成されない。実際に、一実施形態によると、分散システムにおける全サーバノードサーバは、同時の取引顧客のアクセス要求又は取引中のトランザクションに対応するように構成される。その結果、これにより、分散システムを、作業負荷が増加するに従いパフォーマンスを犠牲にせずに、更なるサーバノードに対応するように容易に拡大可能になる。一実施形態によると、本オンライン取引では、パッシブな待機サーバが存在せず、単一のマスタ調整サーバノードの脆弱性やボトルネックは、完全に排除される。その上、複数のサーバノード１０２、１０４、１０６（及び／又は図１では図示しない他のもの）に亘り顧客トランザクション要求を分散することで、全ての使用可能なサーバノード上の処理負荷やトラフィックを本質的に分散する。また、サーバノード１０２、１０４、１０６に亘りアクティブな負荷の平均化も行われ得る。

一実施形態によると、売／買値提案は、クライアントによって提出され、ＤＣｏｎＥによって受信され、合意され、シリアル化され、状態機械によって使われる大域的シーケンスに順序付けられ、その後、買値に対して売値をマッチングさせる。状態機械は、ＤＣｏｎＥ１０８が提案を複数回返す可能性があるため、確実に、提案を、冪等法（一度又は複数回実行されるならば、提案が同じ結果となる）で顧客ノードに亘り取引アプリケーションによって処理する。一実施形態では、ＤＣｏｎＥ１０８は、あるサーバノードで提案ｐがｑの前に提出されたならば、大域的シーケンスでは、ｐはｑの前に出現するという、ＦＩＦＯ順序を保証する。

かかる売買プラットホームは、そのため、売買、売値又は買値を受諾するように構成され得る。一実装では、かかる売値及び買値の要求は、同じ価格を有する複数の売買に直面する際、第一に価格の競争力、第二に提出時間で優先順位付けされ得る。他の実装では、他の特性を優先させ得る。取引の各顧客は、一意のＩＤによって識別され得る。

一実施形態によると、取引アプリケーションは、自身に対する買い及び売り、又は顧客の現在の口座残高を超える売買を防止する等、幾つかの常識的なビジネスルールを実施するように更に構成され得、実装され得る。例えば、一実装において、買指値Ｘ_ｂが、受信され、該買指値Ｘ_ｂが現在の最良売価格Ｘ_ａより高く、その後ほぼ成り行き注文になった場合、この売買は、直ぐに、しかし、一実装では、（Ｘ_ａ＋Ｘ_ｂ）／２の価格で、成立され得、それによって、買い手と売り手双方の期待を上回るのが好ましい。他の注文成立方法も使用され得る。一実施形態によると、一旦売買が発注されると、その売買は、取消しできない。トランザクションには、少額のトランザクション料金が徴収され得、トランザクション料金は、取引プラットホーム提供者の利益になり得る。また、本実装では、流動性を提供するためにマーケットメーカは全く存在しないと仮定する。

ＤＣｏｎＥは、一実施形態によると、極めて望ましいフォールトトレラント性を可能にする；即ち、全取引トランザクションの分散及び／又は複製台帳が、全サーバノードに亘り、ノード又は通信リンクの不具合下でも、一貫性を保てる。一実施形態によると、成立した注文は、複製／分散台帳に記入され得、該台帳は、各トランザクションに対して、少なくとも一意のトランザクションＩＤ、一意の買い手ＩＤ、一意の売り手ＩＤ、売買価格、及びトランザクション時刻を記憶する。台帳記入は、一実施形態によると、他のフォーマットも可能であるが、ＸＭＬでフォーマットされ得る。

全ての提出された買値及び売値の提案の取扱いが完了しており、新たな買値又は売値提案がなく、分散システムのあらゆるサーバノードが、全ての提出された提案を認識しているならば、本分散システムの取引は、休止状態になるとされる。確実に、全ノードに亘るデータを、不具合下で休止状態においても、同じにする一方法は、ブラウザを使用して各サーバノードからのデータをクエリし、検査することによるものである。その目的に向けて、一実施形態は、例えば、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）ＡＰＩを利用して、ブラウザを使用して異なるノードからの台帳を検査可能にし得る。ＲＥＳＴは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に基づいて、制約と特性のセットを定義するアーキテクチャ様式である。ＲＥＳＴのアーキテクチャ様式に準拠するＷｅｂサービス、又はＲＥＳＴｆｕｌ Ｗｅｂサービスは、インターネット上のコンピュータシステム間で相互運用性を提供する。ＲＥＳＴ対応のＷｅｂサービスにより、要求システムが、均一な所定のステートレス動作のセットを使用して、Ｗｅｂリソースのテキスト表現にアクセスし、操作可能になる。ＲＥＳＴ ＡＰＩは、異なるノードからの複製され、維持された一貫した台帳を、ブラウザから検査可能にする。ＲＥＳＴのエンドポイントは、該ポイントをブラウザが指して、顧客の売買履歴を見られるように、提供され得る。他のＡＰＩも、本文脈の範囲内で使用され得る。
取引のアーキテクチャ

図２は、３つのノードインスタンスで、一実施形態による取引のアーキテクチャの態様を示している。一実施形態によると、取引２００は、ＤＣｏｎＥによって生成され送られた大域的に順序化された売買からイベント（この場合、買値及び売値）をデキューすることによってその売買を決済するように、及び例示目的のみで、売値決済（ｐ，ｑ）と呼ばれる決済アプリケーションプロセスにおいて、デキューされた売買を使用するように、構成され得る。

一実施形態において、取引２００では、どの参加者も悪意がないものと仮定する；即ち、取引では、取引を利用する当事者らは、信頼できると仮定する。一実施形態では、そのため、取引２００は、ＤＣｏｎＥ１０８自体もそうであり得るように、所謂非ビザンチンモデル（ｎｏｎ−Ｂｙｚａｎｔｉｎｅ ｍｏｄｅｌ）に基づいて構成され得る。取引顧客は、適宜、適当な識別情報を提供することによって取引に登録し、法定不換紙幣、暗号通貨、金又は他の価値のデジタル認印を預け、適宜、一意の買い手及び／又は売り手ＩＤを受取る。例えば、金／現金の所有権の証拠を提供することは、状況、場所、及び管轄によって異なり得る。実際に、顧客登録、新規口座への金／現金の預金等を伴う、物質的世界とデジタルとの接点（ｉｎｔｅｒｆａｃｅ）については、本明細書では更に触れない。

図２に示したように、取引顧客は、例えば、プリティグッドプライバシ（ＰＧＰ：Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ）暗号プロトコルの公開鍵を使用して、安全で、デジタル署名された売買を発行し得る。売買は、２０２で参照されるノード１、２０４で参照されるノード２及び２０６で参照されるノード３で示したように、ネットワーク上のサーバノードから発生し得る。即ち、取引顧客は、サーバノードの１つに対して買値又は売値を発行し、該買値又は売値は、他の情報（買い手又は売り手のアイデンティティ、タイムスタンプ等）と共に提案にカプセル化されて、ＤＣｏｎＥ１０８に転送され得る。図２で示した実施例では、２０２のノード１は、２提案を発行し、該提案のそれぞれは、所定量の価値のあるもの又はサービスに対するタイムスタンプ付き買値又は売値であり得る。本明細書に記載した例示的なＡｕＸ実装では、買値又は売値は、特定量の金に対するものとなろう。この実施例では、ノード２は、２０２でかかる４提案を発行し、ノード３は、２０６で取引２００に対して３提案を発行する。機能上、取引顧客は、取引アプリケーションにログオンして、買い（買値）又は売り（売値）注文を発行し得る。この買値又は売値注文は、暗号化され（売買ペイロードと通信チャネル両方）、ＤＣｏｎＥ１０８に安全に送信され得る。ＤＣｏｎＥ１０８は、全ての参加サーバノードから提案を受信し、該提案の受諾者の役割にあるサーバノードの大部分から全取引トランザクション提案についてコンセンサスを達成し、一実施形態において、合意済み取引トランザクション提案を、それらのタイムスタンプに従い、シリアル化し、順序付けするように、構成され得る。別の実施形態では、合意済み取引トランザクション提案は、該提案がそれらのサーバノードで受信された順序を尊重して；即ち、該提案の局所的シーケンス番号を尊重しながら、順序付けされ得る。シリアル化され、順序付けられた提案は、この様にして、２０８で示したように、順序付けられた大域的シーケンスになる。

図２で示したように、提案２０８の大域的シーケンスは、それぞれ、同じ順序で同じ提案を少なくとも幾つかを含んでおり、暗号化され得、売り注文を買い注文とマッチングできる、及び買い注文を売り注文とマッチングできる分散システムにおける全サーバノードに安全に送信され得る。各サーバノードは、少なくとも、全登録取引顧客の全売買活動の全記録を記憶する−例えば、複製／分散台帳のインスタンス。実際に、一実施形態によると、台帳２１１、２１３、２１５は、それぞれ、各サーバノード２１０、２１２、２１４に維持され、記憶され得る。台帳２１１、２１３、２１５は、それによって記憶されるアイテムを幾つか挙げると、少なくとも買い手の一意の識別子、売り手の一意の識別子、購入される金額、もの又はサービス、及びトランザクションのタイムスタンプを含む、少なくとも取引の完全な履歴を含有する。複製／分散台帳は、各サーバノードにある永続的記憶装置に、又は各サーバノードにアクセス可能な永続的記憶装置に記憶され得る。サーバノード２１０、２１２、２１４に送信される提案２０８の大域的シーケンスそれぞれは、同様に順序付けられ（同数の順序付けられた提案を含むとは限らないが）、これら提案における構成要素たる買値／売値は、取引アプリケーションによって、複数のサーバノードそれぞれで同じ順序で使われるため、また各サーバノードにおいて同じ方法で買値が売値とマッチングされるため、台帳２１１、２１３、２１５は、サーバノードに亘り、一貫した方法で更新され得、同じである、又は経時的に同じになることが確実である。実際に、各台帳２１１、２１３、２１５は、瞬時に、同じとはならないかも知れないが、変化が該台帳に適用される順序や方法が同じであり、決まった、予測可能なやり方で状態を変化させるため、各台帳は、経時的に同じになることが確実である。

図２に示したように、サーバノードは、提案の大域的シーケンスの提案を受信し、該提案を、売値提案と買値提案に分別する。一実施形態によると、売値提案は、売値の最小ヒープに供給され、買値提案は、買値の最大ヒープに供給される。本明細書では、ヒープは、ヒープ特性を満足する専門的な木に基づくデータ構造として定義される：Ｐが、Ｃの親ノードであれば、Ｐのキー（値）は、最小ヒープに関してＣのキー以下になり、最大ヒープに関しては、Ｐのキーは、Ｃのキー以上になる。ヒープの「最上位」にあるノード（親がいない最小ヒープ構造のノード）は、根ノードと呼ばれる。例示目的で、取引２００が金取引であること、及び顧客Ｃが、単位当たり価格ｐでｑ単位の金を売るという売買Ｔを行うと仮定しよう。（同様のアルゴリズムが、買い／買い唱えに対して実装され得る。）一実施形態によると、ｑ単位の金を価格ｐで売値決済するプロセス、又は売値決済（ｐ，ｑ）は、以下のように構成され得る。冪等性は、ＤＣｏｎＥ１０８がＴを含む提案を伝えると、売買Ｔが以前に処理されたことがあるかを判定するようチェックすることを求める。処理されたことがある場合、売買は繰り返されない。売買Ｔが以前に処理されたことがない場合、売買は、進行され得る。適当なビジネスロジック及び／又は常識は、例えば、取引１０８を行うＣの口座に、事実上、少なくともＣが売りたい量の金があることを確実にするのに−売り手が集団でないと仮定する−適用され得る。他のビジネスロジック及び／又は規則も適用されて、確実に、取引顧客Ｃが、ｐより高額で、取引に対して突出した買値を付けない等とし得る。Ｔを含む提案が、これらの閾値テストの何れかに不合格であるならば、売買Ｔは、進行するべきでない、又は更なる認証、保証人又は担保のために遅延保留され得る。

売買Ｔを成立させるために、一実施形態によると、売買Ｔが売値最小ヒープ（Ａ_ｍｉｎ）に挿入され得る。その後、両ヒープの根を互いにマッチングするような試みが行われる。効率的な市場では、最良売値と最良買値は、等しくなければ、大抵、互いに極めて近くなる可能性が高い点に、注目されたい。実際に、Ａ_ｍｉｎの根ノードで示されたような最良売値価格ｐ_askが、買値最大ヒープＢ_ｍａｘの根ノードで示されたような最良買値価格ｐ_ｂｉｄ以下であるならば、Ａ_ｍｉｎとＢ_ｍａｘ両方の根ノードは削除され、この売買ペアは、この実装では、現在日時の日時スタンプ付きで、（ｐ_ａｓｋ＋ｐ_ｂｉｄ）／２の決済価格と共に複製／分散台帳に書き込まれ得る。同様な決済買値（ｐ，ｑ）は、当業者が認識し得るように、考案され得る。有効な買い手と有効な売り手をマッチングする他の方法は、本開示の文脈の範囲内で開発され得る。この様に、最小ヒープＡ_ｍｉｎと最大ヒープＢ_ｍａｘは、経時的に変化（ｅｖｏｌｖｅ）し、台帳２１１、２１３及び２１５は、同じ順序でトランザクションをそれぞれ記録して、経時的に、成長する。台帳２１１、２１３及び２１５を備える複製台帳が、同じになるよう維持されるとき、複製台帳のどの構成インスタンスを変更しようとする悪意のある試みも、他の台帳インスタンスが合意状態でなくなるため、また、台帳の他のインスタンスへの変化を伝播するメカニズム、又は２０８に示した大域的に順序化された（ＧＳＮによって）売買を通す以外に台帳を変化させるメカニズムが全く存在しないため、成功しないであろう。
局所的シーケンスの保存

特定のサーバノードが、先着順又は先入れ先出しを実装し、取引トランザクション提案の取扱いを、到着時間に基づいて処理し、確実に該提案を、同じ順序で出力することが、因果順序要件であるときもある。上述したように、関係する提案が２つの異なるノードに提出された場合、かかる方針に対するソリューションは、全く存在しない。同じノードに提出されると、一実施形態は、前処理及び後処理ステップを通して、このＦＩＦＯ制約を満足する。実際に、一実施形態によると、取引トランザクション提案Ｐ_０及びＰ_ｔが同じノードに提出されると、この局所的シーケンス保存制約は、前処理と後処理ステップを加えることによって満足できることが、示されている。一実施形態による前処理ステップは、ＤＣｏｎＥ１０８への取引トランザクション提案の到着時に局所的シーケンス番号（ＬＳＮ）を割当てることを含み得る。ＬＳＮは、一意であるだけでよく、継続する、連続する又は単調である必要はない。事実上、ＬＳＮは、番号である必要はない−ＬＳＮは、ストリングである又はストリングを組み込み得る。ＬＳＮに関する唯一の要件は、一意性である。一実施形態によると、取引トランザクション提案番号Ｐは、そこから２つの値を導出し得るように構成されるべきである：
１．取引トランザクション提案Ｐが受信されたサーバノードＮのアイデンティティ、
２．一番目を除く全取引提案に関して、取引トランザクション提案Ｐの到着直前にサーバノードＮに到着した取引トランザクション提案のＬＳＮ。ここでのこの先行取引トランザクション提案は、Ｐの先行値と呼ばれる。

一実施形態では、サーバノードＮでのＬＳＮ付番スキームは、単にＮ_１、Ｎ_２、Ｎ_３、…であり得る。Ｎ_ｉを考えると、それが到着したサーバノードＮは、Ｎ_ｉから導出され、全てに関して、ｉ＞１であり、Ｎ_ｉの前のサーバノードＮで受信された取引トランザクション提案（Ｐ_ｉの先行値）は、Ｎ_{（ｉ−１）}となる。

ある理由で、連番を生成できないが、単調に増加する番号の源へのアクセスが利用可能であるならば、ＬＳＮ付番は、２つの組（ｔｕｐｌｅ）として構成され得る：Ｎ_ｊがＮ_ｉ直後に出現し、ｊ≠（ｉ＋１）ならば、ＬＳＮは、単に＜Ｎ_ｊ，（ｊ−ｉ）＞となる。＜Ｎ_ｊ，（ｊ−ｉ）＞から、我々は、取引トランザクション提案が、ノードＮに到着したことを再度判断でき、Ｎ_ｊの先行値は、第２組（ｊ−ｉ）を下付き文字ｊから引くことによって求められ、それがＮ_ｉであると結論づけできる。他のＬＳＮ付番スキームも考案され得る。

一実施形態によると、後処理ステップは、確実に、局所的シーケンスが、ＤＣｏｎＥによって生成された取引トランザクション提案の大域的に順序付けられたシーケンスで尊重されるように、実行され得る。一実施形態では、取引トランザクション提案がコンセンサスプロセスを受けた後に、全取引ノードから発する取引トランザクション提案の混合である出力シーケンスが、ＤＣｏｎＥによって生成されるとき、全サーバノードから受信された各取引トランザクション提案は、本明細書でＧＳＮ'と呼ぶ、仮大域的シーケンス番号に関連付けられ得る。ＧＳＮ'は、合意済み取引トランザクション提案（即ち、ＤＣｏｎＥを通してコンセンサスに到達した取引トランザクション提案）と関連付けられる番号（又は、他の一意の識別子）の順序付けられたシーケンスである。特定のサーバノードから発する構成取引トランザクション提案が、ＧＳＮ'において出現する順序は、その特定のノードからのＬＳＮを尊重しないかも知れない（しかし、尊重する可能性もある）。各サーバノードのためのＬＳＮがＧＳＮ'において尊重されることが望まれる（本取引又は市場等の実装時のように）場合、一実施形態による後処理ステップは、各サーバノードに対する取引トランザクション提案のその局所的順序付けを強制するために、実行され得る。

一実施形態によると、以下に示すように、後処理は、別の大域的シーケンス番号、ＧＳＮを作成するようＧＳＮ'を変更する。これらの後処理ステップは、ＧＳＮが以下の望ましい特性を有することを保証する：取引トランザクション提案Ｐ_ｉが、ノードＮでＤＣｏｎＥに対する入力キューにおいて、取引トランザクション提案Ｐｊの前に出現したならば、取引トランザクション提案Ｐ_ｉは、ＧＳＮにおいて取引トランザクション提案Ｐ_ｊ前に出現するであろう。

確実に、各ノードのためのＬＳＮがＧＳＮにおいて尊重されるために、以下が、実行され得る。ＤＣｏｎＥに参加しているｎノードが存在する場合、ｎ最小ヒープ、Ｈ_１、Ｈ_２、…、Ｈ_ｎが、作成され得、１つの最小ヒープは、取引を含む分散システムの各サーバノードに対応する。また、一実施形態によると、後処理は、ｎ変数ｐｒｏｃｅｓｓｅｄＰｒｏｐｏｓａｌＮｏ_ｉを作成することを含み得、そこでは、１?ｉ?ｎであり、各サーバノードに対する１つのかかる変数は、出力された最新の取引トランザクション提案番号を追跡記録する。初めは、これらの変数は未定義である。

一実施形態によると、仮大域的シーケンス番号ＧＳＮ'からの取引提案Ｐは、以下のように処理され得る。実際に、サーバノードｘによって提出された取引提案Ｐ_ｉは、以下のように処理され得る：
ａ．取引提案Ｐ_ｉを、サーバノードｘのための最小ヒープＨ_ｘに挿入する。Ｈ_ｘの根は、Ｐ_ｒｏｏｔと呼ばれる。
ｂ．（ｐｒｏｃｅｓｓｅｄＰｒｏｐｏｓａｌＮｏ_ｘ＝＝Ｐ_ｒｏｏｔの先行値）である間
／／ブール条件（未定義の＝＝Ｐ_１）は、定義上、真と評価する。
ｉ．Ｈ_ｘからＰ_ｒｏｏｔを削除する。
ｉｉ．Ｐ_ｒｏｏｔをＧＳＮに追加する。
ｉｉｉ．Ｐ_ｒｏｏｔを変数ｐｒｏｃｅｓｓｅｄＰｒｏｐｏｓａｌＮｏ_ｘに書き込む。

その先行値がＧＳＮに出現していない提案Ｐは、待機状態になる。これは、ＰをＧＳＮ'からデキューし、それを、Ｐが提出されたノードに対応する最小ヒープ（優先キューとしても知られる）にエンキューすることによって、行われる。自分の先行値がＧＳＮにあるか（Ｉｓ ｍｙ ｐｒｅｄｅｃｅｓｓｏｒ ｏｎ ＧＳＮ？）という条件が、変数ｐｒｏｃｅｓｓｅｄＰｒｏｐｏｓａｌＮｏを調べることによって、チェックされる。更にまた、この条件は、チェックされ、提案は、ヒープが空になるか、又は条件がもう真ではなくなるまで、繰り返しＧＳＮに出力される。

図３は、ＤＣｏｎＥによって生成された合意済み取引トランザクション提案のシーケンスを、取引トランザクション提案が、取引において発生する各ノードによって、ＤＣｏｎＥ１０８に送信されたときに、取引トランザクション提案の局所的順序付けを尊重するように、処理するコンピュータ実装方法３００の態様について、説明している。幾つかの用途では、ＧＳＮに局所的順序付けを尊重させることは、不要である。しかしながら、他の用途では、公平性を考慮すると、取引トランザクション提案の局所的順序付けを厳格に尊重することが必要となる。そのために、一実施形態では、局所的シーケンスを尊重するために、いかなる再順序付けもせずに、ＤＣｏｎＥ１０８によるＧＳＮ出力を利用するように構成され得る。別の実施形態は、各ノードにおける取引トランザクション提案の局所的順序付けが、ＤＣｏｎＥ１０８によって生成された合意のシーケンスにおいて尊重されるように、ＤＣｏｎＥ１０８のＧＳＮ出力が、適宜、再順序付けされるように、構成され得る。例えば、コマンドライン「切換え（ｓｗｉｔｃｈ）」又は他の機能は、ＤＣｏｎＥからの合意出力のシーケンスの再順序付けを、選択的に有効化又は無効化して、取引トランザクション提案を、ＤＣｏｎＥ１０８による合意出力のシーケンスに寄与する各ノードにおける対応する取引トランザクション提案の順序付けを尊重（例えば、順守）するために、提供され得る。

図示したように、３つのサーバノード；即ち、ノード１、ノード２及びノード３は、取引所と結合され、取引トランザクション提案をＤＣｏｎＥ１０８に送信する。実際に、サーバノード１（ノード１）は、３０２で示したように、取引トランザクション提案Ｘ_４、Ｘ_３、Ｘ_２及びＸ_１を、ＤＣｏｎＥ１０８に送信し、サーバノード２（ノード２）は、３０４で示したように、取引トランザクション提案Ｙ_４、Ｙ_３、Ｙ_２、及びＹ_１を、ＤＣｏｎＥ１０８に送信し、サーバノード３（ノード３）は、３０６で示したように、取引トランザクション提案Ｚ_４、Ｚ_３、Ｚ_２、及びＺ_１を、ＤＣｏｎＥ１０８に送信する。インデックスが低い程、到着時間が早いことを示す。これらの提案は、ＤＣｏｎＥ１０８によって受信され、ＤＣｏｎＥ１０８は、コンセンサスプロトコルを通して、受信された取引トランザクション提案について合意を達成し、（例示的な）順序付けられた仮大域的シーケンスＧＳＮ'を出力するが、該シーケンスは、合意済み取引トランザクション提案（今後、単に合意と呼ぶ）の順序付けられたシーケンスＸ_１Ｚ_２Ｙ_３Ｘ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１から成り、このシーケンスは、ノード１、２及び３それぞれからの合意済み取引トランザクション提案を含む。

そのため、図３では、局所的に順序付けられた署名済み取引トランザクション提案（又は、図３に示したような売買）３０２、３０４、３０６が、それぞれノード１、２、及び３から、ＤＣｏｎＥ１０８で受信される。しかしながら、仮ＧＳＮ'は、各ノードから発する提案の局所的順序付けを尊重しないかも知れない（が、恐らく尊重する可能性はある）。例えば、ＧＳＮ'（後端）Ｘ_１Ｚ_２Ｙ_３Ｘ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１（先端）では、合意Ｚ_３は、Ｚ_１の前に出現し、Ｚ_１は、Ｚ提案が、ノード３によってＤＣｏｎＥ１０８に提出された順序；即ちＺ_４、Ｚ_３、Ｚ_２及びＺ_１を尊重しない。そのため、一実施形態によると、ＧＳＮ'の構成合意は、３１０で示したＧＳＮに、再順序付けされ得る。ＧＳＮ３１０は、その構成合意が、各ノードにおいて対応する取引トランザクション提案の局所的順序を尊重するように、順序付けされる。ＧＳＮ'３０９とＧＳＮ３１０間におけるこの再順序付けを実現する後処理は、３０５で、３０３及び３０７で起こる同じ後処理と共に、示されている。

図３は、仮ＧＳＮ'３０９を受取り、再順序付けされたＧＳＮ３１０を出力する後処理ステップ時のスナップショットである。図示したように、仮ＧＳＮ'３０９は、後処理のために、必ずしも同時ではないが、３つのノード１、２及び３全てに同様に出力される。再順序付けプロセスが決定論的であるとき、同じ入力は、常に同じ出力をもたらし、それによって、同じＧＳＮ３１０が、ノード１、ノード２及びノード３に同様に出力されるのを保証し、各ノードは、次に、基本的な取引トランザクションを実行し、同じ順序で複製台帳を更新する。図３で示した時のスナップショットは、説明目的で、ノード１が、現時点でＧＳＮ'のＹ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分を処理中であり、そのために３１２で、Ｘ_１Ｚ_２Ｙ_３Ｘ_３が後処理待ち状態のままにして、撮られている。同様に、ノード２は、現時点でＧＳＮ'のＸ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分を処理中であり、そのために３１４で、Ｘ_１Ｚ_２Ｙ_３が後処理待ち状態のままにしている。最後に、ノード３は、現時点でＧＳＮ'のＸ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分だけを処理中であり、そのために３１６で、ＧＳＮ'のＸ_１Ｚ_２Ｙ_３Ｘ_３Ｙ_２の比較的大きな部分が後処理待ち状態のままにしている。意味深いことには、ノード１、ノード２及びノード３は、異なる速さで、ＧＳＮ'における合意を処理し得、同時に同じ合意を全て処理し得ないが、これらのノードは、全て、同じ順序でＧＳＮ'から同じ合意が供給され、該合意を同じ方法で処理して、同じＧＳＮをもたらす。これにより、確実に、基本的なトランザクションが、各ノードで同じ順序で実行され、各ノードが、同じ順序で分散／複製台帳のそのコピーを更新する。これは、経時的に、完了したトランザクションの分散／複製台帳が、ノードに亘り同じある（又は同じになる）ことを意味する。

図３は、ノード２での後処理について、ノード１とノード３が、同じ後処理ステップを、仮ＧＳＮ'３０９の構成合意に、使用することが分かる状態で、示している。図示したように、最小ヒープは、各ノードに提供される。ノード２において、そのため、最小ヒープが、ノード１に提供され、別の最小ヒープが、ノード２に提供され、また別の最小ヒープが、ノード２において、ノード３に提供され、ＤＣｏｎＥ１０８に提案を供給するノードそれぞれに対して１つの最小ヒープが提供される。これらの最小ヒープにはそれぞれ、それらの発生源のノードに対応するＧＳＮ'３０９からの合意が入力（ｐｏｐｕｌａｔｅ）される。上述したように、ノード２は、現時点でＧＳＮ'のＸ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分を処理中であり、そのため、３１４で、Ｘ_１Ｚ_２Ｙ_３を後処理待ち状態のままにしている。合意Ｙ_１は、ノード２で後処理される最初の合意である。Ｙ１には先行値が全くないため、図３のＧＳＮ３１０の先端に示すように、Ｙ１は、直接ＧＳＮに渡される。次に、Ｚ３が処理される。Ｚ３の先行値であるＺ２が、処理されていないため、Ｚ３は、ノード３に対応するヒープに挿入される。Ｚ_１は、現時点でノード２で後処理中のＧＳＮ'のＸ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分に存在していることに注目されたい。そのため、全Ｚ合意中の最低インデックス値を有する合意Ｚ_１は、直接ＧＳＮに、Ｙ_１の左に（後に）移動される。そのため、Ｚ１は、最後に処理された提案＃位置に移動され、合意Ｚ３とＺ４は、まだ最小ヒープに留まり、それらの先行値の到着を待つ：Ｚ３は、Ｚ２を待ち、Ｚ４は、Ｚ３を待ち、次に進む。ノード３の最小ヒープは、図示したように、根の位置でＺ３と共にある。現時点で後処理中のＧＳＮ'の部分に次に遭遇するのは、Ｘ_２である。Ｘ_１は、現時点でノード２によって処理中のＧＳＮ'のＸ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分に存在していないため、どのＸ合意も、この時点でＧＳＮに出力できず、そのため、ノード１合意に対して最後に処理される提案＃は、「未定義」に設定される。実際に、Ｘ_１は、図３で、３１４に示したような、後処理を待つものとして、示されている。そのために、実際に、現時点でノード２によって処理中のＧＳＮ'のＸ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分に存在するＸ_２、Ｘ_３及びＸ_４は、ノード１に対するノード２の最小ヒープを、Ｘ_２を根位置にして、入力するのに使用される。その後、合意Ｙ_４が処理される。Ｙ_２は、現時点でノード２によって処理中のＧＳＮ'のＸ_３Ｙ_２Ｘ_４Ｚ_１Ｙ_４Ｚ_４Ｘ_２Ｚ_３Ｙ_１部分に存在しており、Ｙ合意中の次に最も低いインデックスを有しているため、Ｙ_２は、ＧＳＮに出力され、ノード２に対して最後に処理された提案＃（上記プロセスのｐｒｏｃｅｓｓｅｄＰｒｏｐｏｓａｌＮｏ_２）として記録され、Ｙ_４は、ノード２の最小ヒープの根に移動される。これまでのところ、この後処理では、部分的なＧＳＮ３１７のＹ_２Ｚ_１Ｙ_１を出力済みであり、Ｙ_２Ｚ_１Ｙ_１は、３１０で示したＧＳＮの先端を構成する。ＧＳＮ'の他の構成合意は、同じ方法で処理され、ＧＳＮ３１０をもたらす。

実際に、Ｙ_３は、その後、３１４で後処理されるのを待つ合意から処理されるだろう。Ｙ_３の先行値である、合意Ｙ２が、最後に処理された提案＃であったため、Ｙ_３は、直接ＧＳＮ３１０に、Ｙ_２の左に出力でき、そうなるとＹ_３は、最後に処理された提案＃として入ることができ、それによって、Ｙ_４が次にＧＳＮ３１０に来ることが可能になる。同様に、Ｚ_２が後処理されると、まだ処理されていない最低インデックス値があると判断され、それによって、Ｚ_２が直接ＧＳＮ３１０へと移動可能にされ、ノード３の最小ヒープからのＺ_３とＺ_４が続く。最後に、Ｘ_１が後処理され、先行値が全くないと判断され、Ｚ_４の後に直接ＧＳＮ３１０に送信され、ノードの１の最小ヒープにおける残りのＸ合意が、最小インデックス値から最大インデックス値まで続く。そのため、ノード１の最小ヒープの根；即ち、Ｘ_２は、ＧＳＮ３１０に移動され、ノード１に対して最後に処理された提案＃として識別され、そうなると、合意Ｘ_３は、根の位置につく。その後、Ｘ_３は、ＧＳＮ３１０に出力され、最後に処理された提案＃として割当てられ、Ｘ４は、ノード１の最小ヒープの根の位置に移動され、ＧＳＮ３１０に移動される。このプロセスの結果、合意Ｘ_４Ｘ_３Ｘ_２Ｘ_１Ｚ_４Ｚ_３Ｚ_２Ｙ_４Ｙ_３Ｙ_２Ｚ_１Ｙ_１の順序が、各ノードで生成された対応する取引トランザクション提案の局所的順序付けを尊重するＧＳＮ３１０となる。実際に、ＧＳＮ３１０では、ＧＳＮ'３０９と異なり、Ｚ_３はもうＺ_１前のシーケンスに出現しなくなり、これは、ＤＣｏｎＥ１０８に提出された対応する取引トランザクション提案の局所的順序付けを尊重している点に注目されたい。
暗号化によるセキュリティ

本明細書に開示した取引の一実施形態では、どの参加者も悪意がないものと仮定する。実際に、一実施形態は、ＤＣｏｎＥ１０８もそうであり得るように、所謂非ビザンチンモデルに基づいて構築される。図４は、各計算ノードが１つ又は複数のサーバノードを備える複数の計算ノードを備える例示的な取引を示しており、一実施形態による取引のセキュリティとプライバシー機能について説明している。図４のブロック図は、端末相互間のセキュリティを達成するために、暗号化や他のセキュリティプロトコルを採用され得る様々な場所を示している。図示したように、各ノード；即ち、ノード１ ４０２、ノード２ ４０４及びノード３ ４０６は、図１、図２及び図３で示し、それらに関して記載したように、複数のサーバノードを備え得、それぞれＤＣｏｎＥのインスタンスを備え得る。各ノード４０２、４０４、４０６は、例えば、インターネットを含むネットワークと結合され得る。ＤＣｏｎＥのインスタンスは、安全な通信チャネルを介して、コンセンサス（取引トランザクション提案の合意）を達成するために、計算ノード間で安全に通信し得る。一実施形態では、ノード間通信は、セキュアソケットリンク（ＳＳＬ）プロトコルを利用し得る。一実施形態によると、買値と売値は、一実装では、顧客のプリティグッドプライバシ（ＰＧＰ）の秘密鍵を使用して署名され得、ＤＣｏｎＥエンドで、顧客のＰＧＰ公開鍵で認証され得る。他の暗号化プロトコルも利用され得る。取引サーバへの送信及び応答、売買確認及び他の情報は、顧客の演算装置に、例えば、ＨＴＴＰセキュア（ＨＴＴＰＳ又はＨＴＴＰ ｏｖｅｒ ＳＳＬ）を通したＸＭＬメッセージとして、通信し返し得る。

匿名性が事実上望まれる場合、顧客の匿名性の態様は、取引が行われる規制環境に関する機能であり得る。一実施形態では、顧客Ｃは、登録時に公開／秘密鍵のペアを生成することによって匿名でトランザクションでき、このペアの公開鍵部分を使用して、Ｃが所有するアカウントと関連付けできる。取引は、売買が発生したアカウントと関連付けられた秘密鍵を使用して、顧客が各売買に署名することを要求することによって、否認防止を達成し得る。売買は、一実施形態では、５１２ビット等の設定可能なビット数を有するＲＳＡアルゴリズムを使用して、署名され得る。
売買のセキュリティ

顧客Ｃによるアカウントから行われる各売買が、該アカウントと関連付けられる顧客の秘密鍵Ｃ_ｐｒｉｖを使用して、デジタル署名されねばならないため、またＣだけがＣ_ｐｒｉｖを知っているはずであるので、他人は、顧客Ｃを装って不正な売買を行うことができない。一実施形態によると、同じデジタル署名メカニズムでも、Ｃが後で売買を行ったことを否認できないように、Ｃをトランザクションに結び付け得る。一旦売買が成立すると、その売買は、各ノード４０２、４０６、４０８が、台帳の少なくとも１つのコピーを維持した状態で、複製台帳に書き込まれる。一実施形態によると、取引は、２ｆ＋１ノードに関わる実装において、最大ｆノードが同時に故障したときでも、引続き進行し得る（例えば、売値及び買値をマッチングし、トランザクションを処理し、台帳を更新する）。例えば、１１ノード（ｆ＝５）が関わる実装において、５つのノードが同時に故障しても、取引は、引続き進行するだろう。取引が顧客アカウント及び台帳を維持するため、またモデルが非ビザンチンであるので、アカウント及び複製台帳は、全体を通して、耐タンパ性であり続けるであろう。また、一実施形態によると、取引は、ビザンチンモデルに従い構成され得、その場合、取引は、３ｆ＋１ノードに関わる実装において、最大ｆノードが同時に故障したときでも、引続き進行し得る（売値及び買値をマッチングし、トランザクションを処理し、台帳を更新する）。例えば、１６ノード（ｆ＝５）が関わるビザンチン実装において、５つのノードが同時に故障しても、取引は、引続き進行するだろう。

一実施形態によると、取引データベースは、様々なデータ構造、顧客履歴、及び複製台帳自体を備え得る。拡大可能にするために、取引データベースは、複数の分割データベース（ｓｈａｒｄ）に区分けされ得る。例えば、台帳等のデータの一部は、複数の分割データベースそれぞれの中に存在し得る。

本明細書に記載し、図示した分散システムは、ブロックチェーン又は分散台帳技術に基づく分散システムに関連付けられる特性の全てを有する。これらは、コンセンサス、有効性、一意性、不変性、及び否認防止を含む。コンセンサスは、本明細書に記載し、図示した分散調整エンジン１０８−ＤＣｏｎＥ−によって達成される。有効性は、本取引が、例えば、売買を行う口座に、売買を行うのに使用可能な十分な財源（現金又は金）があるのを確認することによって、売買の有効性をチェックするように構成されるため、本分散取引システムで達成される。顧客と顧客の売買両方の有効性を確認する他の方法も、確立され得る。一意性という特性は、許可型ブロックチェーンの性質、及びＡｕＸにおける取引トランザクションの実行に関する決定論的に順序付けられる性質によって得られる。こうした決定論的に順序付けられる取引トランザクションの実行、同様に、これら取引トランザクションを記録する分散台帳に行われる変更に関する決定論的に順序付けられる性質の結果、単一の台帳が分散システム上で分散又は複製され得るとしても、唯一無二の台帳が作成できる。不変性という特性は、台帳が、分散システムによって集合的に保持され、全くどのコピーも変化できないため、得られる。その上、全ノードが誠実（非ビザンチン）であるため、全ノードは、取引の規則に従うと仮定され、台帳は、全ノードに亘り同じであり、その状態で維持される。否認防止という特性は、売買署名用だけでなく、口座残高を保証する等、他の目的用の可能性もある上記秘密鍵によって、得られる。

図５は、一実施形態によるコンピュータ実装方法のフローチャートである。より詳細には、図５は、分散システムでオンライン取引を実装する、及びかかるオンライン取引でブロックチェーンの分散台帳を実装するコンピュータ実装方法のフローチャートである。Ｂ５０２で示したように、この方法は、取引トランザクション提案を、オンライン取引の顧客から複数のサーバノードのコンピュータネットワーク上で受信することを備え得る。複数のサーバノードの各サーバノードは、完了した取引トランザクションの複製台帳のコピーを記憶するように構成され得る。Ｂ５０４で示したように、分散調整エンジンは、コンピュータネットワーク上で、複数のサーバノードに結合され得る。分散調整エンジンは、Ｂ５０６で示したように、複数のサーバノードから複数の局所的に順序付けられた取引トランザクション提案を受信し得る。ブロックＢ５０８は、分散調整エンジンにおいて、複数のサーバノードからの複数の局所的に順序付けられた取引トランザクション提案についてコンセンサスを達成するように求める。次に、Ｂ５１０で、コンピュータ実装方法は、それに応じて、コンセンサスに到達した複数の取引トランザクション提案を含む合意済み取引トランザクション提案の順序付けを生成させ得る。図示したように、合意済み取引トランザクション提案の順序付けは、複数のサーバノードが、オンライン取引において取引トランザクションを実行すべき、及び複製台帳の該取引トランザクションのコピーを更新すべき順序を特定し得る。任意のブロックＢ５１２は、取引トランザクション提案が、複数のサーバノードそれぞれにおいて発行された順序を尊重するために、合意済み取引トランザクション提案の順序付けを再順序付けすること、及び複数の局所的に順序付けられた取引トランザクション提案において再順序付けられた合意済み取引トランザクション提案を提供すること、及び再順序付けられた合意済み取引トランザクション提案を、完全に同じように、複数のサーバノードそれぞれに、実行のために提供することを求める。
１．他の実施形態では、複数のサーバノードによって受信される各取引トランザクション提案は、オンライン取引の顧客によってデジタル署名され得る。複数のサーバノードによって受信される各取引トランザクション提案は、暗号化され得る。一実施形態では、分散調整エンジンは、安全な通信チャネル上で互いに通信する複数の分散調整エンジンインスタンスを備え得る。分散調整エンジンは、合意済み取引トランザクション提案の順序付けを再順序付けして、取引トランザクション提案が、複数のサーバノードそれぞれで発行された順序を尊重するように、及び再順序付けられた合意済み取引トランザクション提案を、完全に同じように、複数のサーバノードそれぞれに、実行のために提供するように、更に構成され得る。分散調整エンジンは、一意の局所的シーケンス番号（ＬＳＮ）を、複数のサーバノードそれぞれから受信された各取引トランザクション提案に割当てるように、更に構成され得る。次に、ＬＳＮは、２つの組＜Ｎ_ｊ，Ｎ_ｉ＞として構成され得、Ｎは、複数のサーバノード中の一意のサーバノードを識別し、Ｎ_ｉとＮ_ｊはそれぞれ、一意の取引トランザクション提案を識別し、Ｎ_ｊは、Ｎ_ｉ直後に到着する。ＬＳＮは、別の方法でも構成され得る。例えば、ＬＳＮは、連番にされ得る。一実施形態では、分散調整エンジンは、複数のサーバノード毎に、各最小ヒープにおいて合意済み取引トランザクション提案をバッファリングすることによって、及び各最小ヒープの各根として最後に処理された合意済み提案番号それぞれを繰り返し識別することによって、合意済み取引トランザクション提案の順序付けを再順序付けして、複数の取引トランザクション提案それぞれにおける取引トランザクション提案の順序を、尊重するように、更に構成され得る。

他の実施形態は、分散システムでオンライン取引を実装する、及び請求項５に関して図示し、記載したようなブロックチェーンの分散台帳を実装する、コンピュータ実施方法、及び、演算装置によって実行されると、該演算装置に、分散システムにおいてオンライン取引を実装させ、図６と関連して図示し、記載したようなブロックチェーンの分散台帳を実装させる命令のシーケンスを表す、その上に記憶されたデータを有する非一時的な機械可読媒体を含み得る。
物理ハードウェア

図６は、実施形態が実装され得る演算装置のブロック図を示す。図６の演算装置は、情報を通信するためのバス６０１又は他の通信メカニズム、及び情報を処理するためにバス６０１と結合される１つ又は複数のプロセッサ６０２を含み得る。演算装置は、プロセッサ６０２（複数可）によって実行される情報及び命令を記憶するためにバス６０１と結合される、ランダムアクセスメモリ（ＲＡＭ）又は他の動的記憶装置６０４（メインメモリと呼ばれる）を更に備え得る。メインメモリ（有形で非一時的であり、この用語は、本明細書では、信号自体や波形を除く）６０４も、プロセッサ６０２によって命令を実行中に、一時変数又は他の中間情報を記憶するのに使用され得る。また、図６の演算装置は、プロセッサ６０２（複数可）のために静的情報や命令を記憶するのにバス６０１に結合されるリードオンリーメモリ（ＲＯＭ）及び／又は他の静的記憶装置６０６も含み得る。磁気ディスク及び／又は固体データ記憶装置等のデータ記憶装置６０７は、図１〜図５に関して図示し、開示した機能を実行するために必要となるであろう−情報や命令を記憶するために、バス６０１に結合され得る。また、演算装置も、情報をコンピュータユーザに表示するために、バス６０１を介して、表示装置６２１に結合され得る。英数字及び他のキーを含む、英数字入力装置６２２は、情報やコマンド選択をプロセッサ６０２（複数可）に通信するために、バス６０１に結合され得る。別の種類のユーザ入力装置は、方向情報やコマンド選択をプロセッサ６０２（複数可）に通信するための、及びディスプレイ６２１上でカーソルの動きを制御するための、マウス、トラックボール又はカーソル指向キー等のカーソル制御装置６２３である。図６の演算装置は、通信インタフェース（例えば、モデム、ネットワークインターフェースカード又はＮＩＣ）６０８を介して、ネットワーク６２６に結合され得る。

図示したように、記憶装置６０７は、６３１で提示したように、磁気ディスク６３０等の直接アクセスデータ記憶装置、不揮発性半導体メモリ（ＥＥＰＲＯＭ、Ｆｌａｓｈ等）６３２、磁気ディスクと不揮発性半導体メモリの両方を備えるハイブリッドデータ記憶装置を含み得る。参照番号６０４、６０６及び６０７は、命令のシーケンスを表す、その上に記憶されたデータを有する有形の非一時的なコンピュータ可読媒体の例であり、該命令は、１つ又は複数の演算装置によって実行されると、本明細書に記載し、図示したオンライン取引及び方法の態様を実装する。これら命令の幾つかは、クライアント演算装置において局所的に記憶され得る一方で、その他のこれら命令は、離れて記憶（及び／又は実行され）、ネットワーク６２６上で演算するクライアントに通信され得る。他の実施形態では、これら命令の全ては、クライアント又は他のスタンドアロン演算装置において局所的に記憶され得る一方で、更に他の実施形態では、これら命令の全ては、離れて（例えば、１つ又は複数のリモートサーバで）記憶、実行され、その結果は、クライアント演算装置に通信される。さらに別の実施形態では、命令（処理論理回路）は、６２８で示したような、別の形の有形の非一時的なコンピュータ可読媒体上に、記憶され得る。例えば、参照番号６２８は、光学（又は、幾つかの他の記憶技術）ディスクとして実装され得、該ディスクは、その上に記憶された命令を、１つ又は複数の演算装置にロードし、それによって、本明細書に記載し、図示した１つ又は複数の実施形態に演算装置（複数可）を再構成するように、適当なデータキャリアを構成し得る。他の実装では、参照番号６２８は、暗号化されたソリッドステートドライブとして具現化され得る。他の実装も可能である。

本発明の実施形態は、ブロックチェーン技術と呼ばれるときもある、分散台帳技術を使用してオンライン取引を実装するために演算装置を使用することに関する。一実施形態によると、本明細書に記載した方法、装置及びシステムは、１つ又は複数の演算装置によって、命令のシーケンスを実行するプロセッサ６０２（複数可）に応答して、提供され得、メモリ６０４に含まれ、本明細書に図示し、記載したコンピュータ実装方法の態様を具現化する。かかる命令は、データ記憶装置６０７、又は６２８で図示したもののような、別の（光学、磁気等）データキャリア等の別のコンピュータ可読媒体からメモリ６０４に読込まれ得る。メモリ６０４に含まれる命令のシーケンスを実行することにより、プロセッサ６０２（複数可）に、ステップを実行させ、本明細書に記載した機能を持たせる。別の実施形態では、ハードワイヤード回路が、ソフトウェア命令の代わりに、又はソフトウェア命令と組合せて、記載した実施形態を実装するのに使用され得る。従って、実施形態は、ハードウェア回路やソフトウェアのいかなる特定の組合せにも限定されない。実際に、任意の適当なコンピュータシステムが、本明細書に記載した機能を実装し得ることを、当業者は、理解するべきである。演算装置は、所望する機能を実行するように作動する１つ又は複数のマイクロプロセッサを含み得る。一実施形態では、マイクロプロセッサ又は複数のマイクロプロセッサによって実行される命令は、該マイクロプロセッサ（複数可）を、本明細書に記載したステップを実行させるように動作可能である。命令は、任意のコンピュータ可読媒体に記憶され得る。一実施形態では、命令は、マイクロプロセッサ外部の、又はマイクロプロセッサと一体化された不揮発性半導体メモリ上に記憶され得る。別の実施形態では、命令は、ディスク上に記憶され、マイクロプロセッサによる実行前に、揮発性半導体メモリに読込まれ得る。

上記の詳細な説明の幾つかの部分では、局所的処理ユニット、該局所的処理ユニット用メモリ記憶装置、ディスプレイ装置、及び入力装置を含むコンピュータ構成要素を含み得る演算装置による、プロセス及び動作の表象（ｓｙｍｂｏｌｉｃ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）について、記載している。更にまた、かかるプロセス及び動作は、例えば、リモートファイルサーバ、コンピュータサーバ、及びメモリ記憶装置を含む異種の分散演算環境でコンピュータ構成要素を利用し得る。これらの分散演算構成要素は、通信ネットワークによって局所的処理ユニットにアクセス可能にし得る。

コンピュータによって実行されるプロセス及び動作は、局所的処理ユニット及び／又はリモートサーバによってデータビットを操作すること、及び１つ又は複数の局所的又はリモートのメモリ記憶装置にあるデータ構造内にこれらビットを維持することを含む。これらのデータ構造は、メモリ記憶装置内に記憶されるデータビットの集合に物理的編成を加え、電磁スペクトル要素を表す。

本明細書に記載し、図示したコンピュータ実装データ拡張方法等のプロセスは、一般的に、所望する結果をもたらすコンピュータで実行されるステップのシーケンスとして定義され得る。これらのステップは、一般的に、物理量の物理的操作を必要とする。通常、必ずしもではないが、これらの量は、記憶、送信、組合せ、比較できる、又は他の方法で操作できる電気信号、磁気信号、又は光信号の形を取り得る。慣習的に、当業者は、これらの信号を、ビット又はバイト（信号が、二値論理レベルを有する場合）、ピクセル値、ワーク、値、要素、記号、文字、用語、番号、ポイント、記録、オブジェクト、画像、ファイル、ディレクトリ、サブディレクトリ等と呼ぶ。しかしながら、これらや同様の用語は、コンピュータ動作のための適切な物理量に関連付けられるべきであること、及びこれらの用語は、コンピュータの動作範囲内及び動作中に存在する物理量に適用される単なる慣習的なラベルであることに、留意すべきである。

また、コンピュータ内での操作は、付加、比較、移動、位置決め、配置、照明、除去、変更する等の用語でしばしば言及されると理解されるべきである。本明細書に記載した動作は、人間又は人工知能エージェントオペレータ、又はコンピュータと対話するユーザによって提供される様々な入力と関連して実行される機械動作である。本明細書に記載した動作を実行するのに使用される機械は、局所的又はリモート汎用デジタルコンピュータ又は他の同様の演算装置を含む。

また、本明細書に記載したプログラム、プロセス、方法等は、いかなる特定のコンピュータ又は装置に関係せず、又は限定されず、いかなる特定の通信ネットワークアーキテクチャに関係しない、又は限定されないと、理解されるべきである。むしろ、様々な種類の、汎用ハードウェアマシンは、本明細書に記載した教示に従い構築されたプログラムモジュールと共に使用され得る。同様に、リードオンリーメモリ等の不揮発性メモリに記憶されたハードワイヤード論理又はプログラムを有する特定のネットワークアーキテクチャの専用コンピュータシステムを通して、本明細書に記載した方法ステップを実行するよう特化した機器を構築すると有利だと判明することがある。

特定の例示の実施形態について説明したが、これらの実施形態は、例示としてのみ提示されたもので、本明細書に開示した実施形態の範囲を限定するよう意図されていない。従って、以上の説明におけるいかなるものも、特定の特徴、特性、ステップ、モジュール、又はブロックが必要又は不可欠であることを含意するよう意図されていない。実際に、本明細書に記載した新規な方法及びシステムは、様々な他の形で具現化され得る；更にまた、本明細書に記載した方法及びシステムの形で、様々な省略、代替及び変更を、本明細書に開示した実施形態の趣旨から逸脱せずに、行い得る。

Claims (24)

1. オンライン取引を実装し、ブロックチェーンの分散台帳を実装する分散システムであって、前記分散システムは：
   複数のサーバノードであって、前記複数のサーバノードの各サーバノードは、前記オンライン取引の顧客から取引トランザクション提案を、コンピュータネットワーク上で受信するように構成され、各サーバノードは、完了した取引トランザクションの分散台帳のコピーを記憶するように構成される、サーバノード；及び
   分散調整エンジンであって、前記分散調整エンジンは、前記コンピュータネットワーク上で、前記複数のサーバノードに結合され、前記複数のサーバノードから複数の取引トランザクション提案を受信するように構成され、前記分散調整エンジンは、前記複数のサーバノードからの前記複数の取引トランザクション提案についてコンセンサスを達成して、それに応じて、コンセンサスに到達した前記複数の取引トランザクション提案を含む、合意済み取引トランザクション提案の同じ順序付けを生成するように更に構成され、合意済み取引トランザクション提案の前記順序付けは、前記複数のサーバノードが、オンライン取引において取引トランザクションを実行すべき、及び前記分散台帳の前記取引トランザクションのコピーを更新すべき順序を特定する、分散調整エンジン
   を備える、分散システム。
2. 前記複数のサーバノードによって受信される各前記取引トランザクション提案は、前記オンライン取引の顧客によってデジタル署名される、請求項１に記載の分散システム。
3. 前記複数のサーバノードによって受信される各前記取引トランザクション提案は、暗号化される、請求項１に記載の分散システム。
4. 前記分散調整エンジンは、安全な通信チャネル上で互いに通信する複数の分散調整エンジンインスタンスを備える、請求項１に記載の分散システム。
5. 前記分散調整エンジンは、合意済み取引トランザクション提案の前記順序付けを再順序付けして、前記取引トランザクション提案が各前記複数のサーバノードで発行された順序を尊重するように、及び前記再順序付けられた合意済み取引トランザクション提案を、完全に同じように、各前記複数のサーバノードに、実行のために提供するように、更に構成される、請求項１に記載の分散システム。
6. 前記分散調整エンジンは、一意の局所的シーケンス番号（ＬＳＮ）を、各前記複数のサーバノードから受信された各前記取引トランザクション提案に割当てるように、更に構成される、請求項１に記載の分散システム。
7. 前記ＬＳＮは、２つの組＜Ｎ_ｊ，Ｎ_ｉ＞として構成され、Ｎは、前記複数のサーバノードの一意のサーバノードを識別し、Ｎ_ｉとＮ_ｊはそれぞれ、一意の取引トランザクション提案を識別し、Ｎ_ｊは、Ｎ_ｉ直後に到着する、請求項６に記載の分散システム。
8. 前記分散調整エンジンは、前記複数のサーバノード毎に、各最小ヒープにおいて前記合意済み取引トランザクション提案をバッファリングすることによって、及び前記各最小ヒープの各根として最後に処理された合意済み提案番号それぞれを繰り返し識別することによって、合意済み取引トランザクション提案の前記順序付けを再順序付けして、各前記複数の取引トランザクション提案における前記取引トランザクション提案の順序を、尊重するように、更に構成される、請求項１に記載の分散システム。
9. 分散システムにおいてオンライン取引を実装し、ブロックチェーンの分散台帳を実装するコンピュータ実装方法であって、前記方法は：
   取引トランザクション提案を、前記オンライン取引の顧客から複数のサーバノードのコンピュータネットワーク上で受信するステップであって、前記複数のサーバノードの各サーバノードは、完了した取引トランザクションの分散台帳のコピーを記憶するように構成される、ステップ；
   前記コンピュータネットワーク上で、分散調整エンジンを、前記複数のサーバノードに結合するステップ；
   前記分散調整エンジンにおいて、前記複数のサーバノードから複数の取引トランザクション提案を受信するステップ；
   前記分散調整エンジンにおいて、前記複数のサーバノードからの前記複数の取引トランザクション提案についてコンセンサスに到達するステップ；及び
   それに応じて、コンセンサスに到達した前記複数の取引トランザクション提案を含む合意済み取引トランザクション提案の順序付けを生成するステップであって、前記合意済み取引トランザクション提案の順序付けは、前記複数のサーバノードが、前記オンライン取引において取引トランザクションを実行すべき、及び前記分散台帳の前記取引トランザクションのコピーを更新すべき順序を特定する、ステップ
   を備えるコンピュータ実装方法。
10. 前記複数のサーバノードによって受信される各前記取引トランザクション提案は、前記オンライン取引の顧客によってデジタル署名される、請求項９に記載のコンピュータ実装方法。
11. 前記複数のサーバノードによって受信される各前記取引トランザクション提案は、暗号化される、請求項９に記載のコンピュータ実装方法。
12. 前記分散調整エンジンは、安全な通信チャネル上で互いに通信する複数の分散調整エンジンインスタンスを備える、請求項９に記載のコンピュータ実装方法。
13. 合意済み取引トランザクション提案の前記順序付けを再順序付けして、前記取引トランザクション提案が、各前記複数のサーバノードで発行された順序を尊重する、ステップ；及び
    前記再順序付けられた合意済み取引トランザクション提案を、完全に同じように、各前記複数のサーバノードに、実行のために提供するステップ
    を更に備える、請求項９に記載のコンピュータ実装方法。
14. 一意の局所的シーケンス番号（ＬＳＮ）を、各前記複数のサーバノードから受信された各前記取引トランザクション提案に割当てるステップを更に備える、請求項９に記載のコンピュータ実装方法。
15. 前記ＬＳＮは、２つの組＜Ｎ_ｊ，Ｎ_ｉ＞として構成され、Ｎは、前記複数のサーバノードの一意のサーバノードを識別し、Ｎ_ｉとＮ_ｊはそれぞれ、一意の取引トランザクション提案を識別し、Ｎ_ｊは、Ｎ_ｉ直後に到着する、請求項１４に記載のコンピュータ実装方法。
16. 合意済み取引トランザクション提案の前記順序付けを再順序付けして、前記複数の局所的に順序付けされた取引トランザクション提案における前記取引トランザクション提案の順序を尊重する、ステップであって、前記ステップは：
    前記複数のサーバノード毎に、各最小ヒープにおいて前記合意済み取引トランザクション提案をバッファリングすること、及び
    前記各最小ヒープの各根として最後に処理された合意済み提案番号それぞれを繰り返し識別すること
    によって行われる、ステップを更に備える、請求項９に記載のコンピュータ実装方法。
17. 命令のシーケンスを表す、その上に記憶されたデータを有する非一時的な機械可読媒体であって、前記命令のシーケンスは、演算装置によって実行されると、前記演算装置に：
    取引トランザクション提案を、前記オンライン取引の顧客から複数のサーバノードのコンピュータネットワーク上で受信し、前記複数のサーバノードの各サーバノードは、完了した取引トランザクションの分散台帳のコピーを記憶するように構成されること；
    前記コンピュータネットワーク上で、分散調整エンジンを、前記複数のサーバノードに結合すること；
    前記分散調整エンジンにおいて、前記複数のサーバノードから複数の取引トランザクション提案を受信すること；
    前記分散調整エンジンにおいて、前記複数のサーバノードからの前記複数の取引トランザクション提案についてコンセンサスを達成すること；及び
    それに応じて、コンセンサスに到達した前記複数の取引トランザクション提案を含む合意済み取引トランザクション提案の順序付けを生成し、前記合意済み取引トランザクション提案の順序付けは、前記複数のサーバノードが、前記オンライン取引において取引トランザクションを実行すべき、及び前記分散台帳の前記取引トランザクションのコピーを更新すべき順序を特定することによって、
    分散システムにおいてオンライン取引を実装させ、ブロックチェーンの分散台帳を実装させる、非一時的な機械可読媒体。
18. 前記複数のサーバノードによって受信される各前記取引トランザクション提案は、前記オンライン取引の顧客によってデジタル署名される、請求項１７に記載の非一時的な機械可読媒体。
19. 前記複数のサーバノードによって受信される各前記取引トランザクション提案は、暗号化される、請求項１７に記載の非一時的な機械可読媒体。
20. 前記分散調整エンジンは、安全な通信チャネル上で互いに通信する複数の分散調整エンジンインスタンスを備える、請求項１７に記載の非一時的な機械可読媒体。
21. 合意済み取引トランザクション提案の前記順序付けを再順序付けして、前記取引トランザクション提案が、前記複数のサーバノードそれぞれで発行された順序を尊重する、命令のシーケンス；及び
    前記再順序付けられた合意済み取引トランザクション提案を、完全に同じように、各前記複数のサーバノードに、実行のために提供する命令のシーケンス
    を更に備える、請求項１７に記載の非一時的な機械可読媒体。
22. 一意の局所的シーケンス番号（ＬＳＮ）を、各前記複数のサーバノードから受信された各前記取引トランザクション提案に割当てる、命令のシーケンス
    を更に備える、請求項１７に記載の非一時的な機械可読媒体。
23. 前記ＬＳＮは、２つの組＜Ｎ_ｊ，Ｎ_ｉ＞として構成され、Ｎは、前記複数のサーバノードの一意のサーバノードを識別し、Ｎ_ｉとＮ_ｊはそれぞれ、一意の取引トランザクション提案を識別し、Ｎ_ｊは、Ｎ_ｉ直後に到着する、請求項２２に記載の非一時的な機械可読媒体。
24. 合意済み取引トランザクション提案の前記順序付けを再順序付けして、前記複数の局所的に順序付けされた取引トランザクション提案における前記取引トランザクション提案の順序を尊重する、命令のシーケンスであって、前記命令のシーケンスは：
    前記複数のサーバノード毎に、各最小ヒープにおいて前記合意済み取引トランザクション提案をバッファリングすること、及び
    前記各最小ヒープの各根として最後に処理された合意済み提案番号それぞれを繰り返し識別すること
    によって行われる、命令のシーケンスを更に備える、請求項１７に記載の非一時的な機械可読媒体。

Images