JP7098660B2 - シャード化された許可型の分散型台帳 - Google Patents

Description

背景
開示の分野
本開示は、概して分散型台帳に関し、より具体的にはシャード化された許可型の分散型台帳に関する。

関連技術の説明
従来、分散型台帳（ブロックチェーンを含む）は典型的にはスケーリングせず、スループットは基本的に、すべての参加者がすべてのトランザクションの伝達、処理および格納を行う必要があるために、限定される。結果として、追加のリソースはスループットの改善につながらないことが多い。「台帳」は、一連のトランザクションを記録するアペンドオンリー（append-only）のデータ構造とみなすことができる。「分散型台帳」は、連続するトランザクションについて合意される共通プロトコルに従うノードの集まりによって管理される台帳である場合がある。「クライアント」は、上記ノードのうちの１つ以上に対してトランザクションをサブミットし得る。いくつかの分散型台帳は、トランザクションをブロックチェーンと呼ばれるブロックに集めることができる。各トランザクション、またはトランザクションのブロックは、台帳内の前のトランザクションのハッシュ（たとえば暗号ハッシュ）を含むことにより、台帳が改ざんされるリスクを最小にすることができる。言い換えると、誰も（またはどのノードも）トランザクションを不正に追加、削除、または変更できない。なぜなら、そうすると、後続のすべてのハッシュも変更することになるからである。Ｂｉｔｃｏｉｎ（登録商標）は、分散型台帳の１つの周知例である。

従来、多くのブロックチェーンおよび分散型台帳システムは十分にスケーリングしない。本明細書において、「ブロックチェーン」という用語は、広く分散型台帳を、たとえ事実上ブロックからなるチェーンとして表されていなくても、意味するために使用される。そのスループットは、参加者の大部分（すなわち場合によってはリソースによって重み付けされる）が、すべてのトランザクションを受信、検証および格納しなければならないという条件によって制限される可能性がある。結果として、追加のリソースはスループットの改善につながらないことが多い。

非許可型ブロックチェーンは典型的に、参加者が台帳の管理に貢献するためにエネルギを費やさねばならないようにすることを確実にすること等によって、故意に非効率的になることがある。Ｂｉｔｃｏｉｎ（登録商標）等の非許可型台帳は一般的に、参加するプロトコルに従うことを希望するいかなるノードも認める。誰もがトランザクションを提案することができ、誰もがどのトランザクションが台帳に記入されるかを決定するプロトコルに参加することができる。一方、許可型の実装例では、特定のノードのみが参加を認められる。たとえば、管轄機関が、どのノードが許可型台帳に参加できるかを制御する場合がある。この管轄機関は、１つの組織、コンソーシアムなどのような各種形態を取ることができる。許可型台帳は、台帳プロトコルを更新するための、または「顧客確認（know your customer）」という金融規則に従うための、整理された手順を提供すること等により、管理を容易にするものとみなすことができる。

正当なノードは、システムのプロトコルに忠実に従うノードとみなすことができ、一方、不正なノード、すなわち敵の制御下にあるノードは、何等かの利益を求めてプロトコルから逸脱する可能性がある。

許可付与は、不正ノードの挙動を、これらを所有するまたはこれらに対する責任を負うアイデンティティに対応付けることを可能にすることが多く、したがって、これらの責任追跡性を保つ可能性を開く。これは、技術的および／または非技術的な手段によって達成し得る。たとえば、あるノードが、明らかに不正をはたらいた場合、プロトコルは、たとえば第三者に寄託されたセキュリティ保証金を没収することまたは不正ノードのさらなる参加を許さないこと等により、ペナルティが自動的に適用されることを可能にし得る。これに代えてまたは加えて、不正行為のエビデンスは法的、規制またはビジネスプロセスに知らされて、有罪の判決およびシステム外で行われるペナルティの決定を可能にする。

当然、完全に独立した複数のブロックチェーンを用いることができる。非許可型ブロックチェーンの場合、この方策には問題があるかもしれない。なぜなら、最も人気のある小数のブロックチェーンを除いて、ほとんどのブロックチェーンには、その管理専用のリソースが少ししかなく、その場合、これらを適度のリソースで圧迫するのは簡単であり、その完全性を損なうであろう。

ブロックチェーンに対する圧力を軽減する２つの方法は、ライトニングネットワークとサイドチェーンである。いずれの場合も、参加者は、「オフチェーン」でやり取りを行い、ごくたまにブロックチェーンに対するトランザクションを実行する。これらの方策は、ブロックチェーンに対する負担を緩和するのに役立つかもしれないが、プライマリチェーンはスケーリングしないという事実を変えることはない。

非許可型の台帳も許可型の分散型台帳も、いくつかのトランザクションを他のトランザクションよりも好む参加者による操作を受けることができる場合がある。ほとんどの台帳プロトコルの中心となるものは、広く一般に合意された一連のトランザクションを確立するために使用されるコンセンサスアルゴリズムであろう。多くの分散型台帳は、実際のところ従来のコンセンサス問題を解決しないが、それでもなおコンセンサスアルゴリズムを実現すると一般的には言われる。いくつかの前のコンセンサスアルゴリズムは、プルーフ・オブ・ワーク（proof-of-work）（ＰｏＷ）システムに基づいており、このシステムにおいて参加者は暗号パズルを解くためにリソースを費やす。しかしながら、ＰｏＷには周知の欠点が２つある。従来、ＰｏＷは、不経済で低速であり、無視できない量のエネルギを消費するよう、かつ台帳にトランザクションをアペンドできるレートを制限するよう、故意に設計されている。この方策は、未知のエンティティの影響を制限することを目的としており、そのコストは許可型台帳において回避し得る。ＰｏＷコンセンサスは確率的補償を提供するだけである。一般的に、ＰｏＷコンセンサスプロトコルの台帳は、２以上の参加者が同時に異なるトランザクションをチェーンにアペンドすると、分岐する（fork）可能性がある。最後には、互換性がないこれらのチェーンのほとんどが放棄されるかもしれないが、どれが存続するかが不確かな期間が存在し得る。結果として、トランザクションは、その後十分な数の後のトランザクションがアペンドされて初めて信頼するに足るとみなすことができる（たとえば台帳が分岐していないことまたはこのトランザクションが分岐に耐えて放棄されなかったことを保証する）。

ＰｏＷコンセンサスに関係するリスクおよび遅延は、許可型台帳において回避できる。なぜなら、参加者は明示的に認証されるので、未知のエンティティによる参加を制限する必要がないからである。これは、非許可型台帳では適用できないさまざまなコンセンサス機構の可能性を開く。

たとえば、許可型の分散型台帳のあるコンセンサス機構は、台帳にアペンドするトランザクション（またはそのブロック）について参加者が提案し投票するプラクティカル・ビザンチン・フォールト・トレランス（Practical Byzantine Fault Tolerance）（ＰＢＦＴ）である。ＰＢＦＴは、参加者のうちの特定の割合（たとえば２／３を上回る）が正当であれば、参加者は台帳に対する有効な追加について合意することを保証し得る。言い換えると、ＰＢＦＴは、参加者のうちの特定の割合（すなわち１／３）未満が、ビザンチンと言われる、たとえばプロトコルから外れて任意に行動する不正な参加者であれば、正当性を保証し得る。しかしながら、ＰＢＦＴは一般的に、ｎ個のノードが合意に達するためにＯ（ｎ^２）個のメッセージを必要とし、これは、たとえトランザクションがブロックになるようバッチ処理されても、多数のノードへのスケーラビリティを妨げるとみなし得る。

もう１つのコンセンサスアルゴリズムは、トランザクションをその台帳にアペンドしこれらをその他の参加者にブロードキャストするリーダーを含み、これは、それらの台帳にこれらを追加し、確認を台帳に送信する。このようなコンセンサスアルゴリズムの一例はＲａｆｔである。リーダーが参加者の大半からの確認を受けると、トランザクションはコミットされたとみなされる。リーダーが反応しなくなった場合、他の参加者が、新たなリーダーを選ぶ選挙を開始できる。一般的な場合、Ｒａｆｔは合意に達するのにＯ（ｎ）個のメッセージしか必要としないので、ＰＢＦＴよりも多数のノードにさらにスケーラブルである。しかしながら、Ｒａｆｔはビザンチン故障に対する耐性がない。たとえば、これは、参加者が互いになりすますこと、腐敗したリーダーが他を騙すことなどを認める。よって、これは、分散型台帳の実装例において使用するのにそのままでは適切でない場合がある。

概要
シャード化された許可型の分散型台帳を実現するための、方法、技術、装置およびシステムについて説明する。本明細書に記載のシャード化された許可型の分散型台帳は、各参加者が必要とする作業および通信の量を減じることにより、以前の分散型台帳実装例には固有であり得るスケーラビリティのボトルネックを場合によっては回避することができ、スループットの増加につながる追加のリソースの使用を場合によっては可能にすることができる。本明細書に記載の方法、技術および／または機構は、複数の「シャード（shard）」からなる台帳をサポートするためのスケーラブルなインフラストラクチャを実現するための方策を提供することができる。上記シャードは各々、それ自体、分散型台帳とみなすことができ、分散型台帳として実現することができる。いくつかの実施形態では、複数のシャードが並列に動作し得る。

シャード化された許可型の分散型台帳への参加は、いくつかの実施形態において、コンソーシアム等の管轄機関の許可によってのみ認められ得る。管轄機関による許可は、このような許可付与の判断が暗に示している信用を活用することを認める場合があるが、誰かまたは何かを完全に信用することはない。また、各種実施形態に従うと、このような許可付与を活用することにより、技術的な各種機構および非技術的な各種機構双方のうちのいずれかを介し、不正をはたらく参加者を検出しその責任追跡性を保つことを、場合によっては保証することができる。

本明細書に記載の方法、技術および／または機構は、シャード化された許可型の分散型台帳を実現するシステムが、所望の行動を指図する（たとえばどの参加者が任意の時点で所定のシャードをアクティブに管理しているかを判断する）、および／または、従わない（たとえば台帳プロトコルおよび／またはコンセンサスアルゴリズムに従わない）ものの責任追跡性を保つ機会を、提供し得る。いくつかの実施形態に従い、本明細書に記載の、シャード化された許可型の分散型台帳は、シャードを管理する参加者からシャードを切り離すことによってサービスの提供を仮想化するスケーラブルインフラストラクチャを利用する（および／または含む）ことにより、場合によっては容量および作業量を互いに独立して増大させることができる。

一実施形態に係るシャード化された許可型の分散型台帳を実現するシステムを示す論理ブロック図である。 一実施形態に係るシャード化された許可型の分散型台帳を管理する責任があるいくつかのノード上のベリファイアを示す論理ブロック図である。 シャード化された許可型の分散型台帳においてシャードにトランザクションを追加する方法の一実施形態を示すフローチャートである。 受信メッセージをディスパッチする方法の一実施形態を示すフローチャートである。 一実施形態に係る、ベリファイアがアクティブになったときにシャードスナップショットを利用する方法の一実施形態を示すフローチャートである。 一実施形態に係るコーディネーションシャードを備えたメンバシップサービスを示す論理図である。 いくつかの実施形態に係るシャード化された許可型の分散型台帳システムを実現するように構成されたコンピューティングデバイスのブロック図である。

本開示は、本明細書において、いくつかの実施形態および説明のための図面について、例示のために記載されているが、当業者は、本開示が記載されている実施形態または図面に限定されないことを理解するであろう。なお、本明細書の図面および詳細な説明は、本開示を開示された特定の形態に限定することを意図しているのではなく、むしろ、本開示は、以下の請求項によって定められる精神および範囲に含まれるすべての修正、均等物、および代替形をカバーするものであることが、理解されねばならない。本明細書で使用されるいずれの見出しも、専ら整理のためであり、本明細書の記載または請求項の範囲を限定することを目的としているのではない。本明細書で使用される「してもよい、し得る（may）」という単語は、義務の意味（すなわち、～ねばならない（must）を意味する）ではなく、許容の意味（すなわち、可能性があることを意味する）で用いられる。同様に、「含む（「include」、「including」、および「includes」）」という単語は、含むことを意味するが、それに限定される訳ではない。

実施形態の詳細な説明
シャード化された許可型の分散型台帳システムを実現するための、方法、技術、装置およびシステムについて説明する。いくつかの実施形態において、シャード化された許可型の分散型台帳は、各参加者が必要とする作業および通信の量を減じることにより、以前の分散型台帳実装例に固有のスケーラビリティのボトルネックを場合によっては回避することができ、かつ、追加のリソースの使用を可能にすることにより、場合によってはスループットを増加させることができる。

モノリシック台帳（たとえば一例はＢｉｔｃｏｉｎ（登録商標））において、台帳におけるトランザクションは、１つの線形シーケンスに配置される。結果として、モノリシック台帳は概ね、本質的に連続しており、新たなトランザクションを台帳に追加することを提案するすべてのノードは、共通コンセンサスプロトコルに参加することによって他のそのようなノードすべてと競合しなければならず、全システムスループットおよびレイテンシは、参加者の数が増えると悪化する傾向がある。

これに対し、シャード化された台帳では、１つの台帳を分割してシャードの集まりにすることができ、各シャードはそれ自体線形台帳であってもよい。関連するトランザクションは同一のシャードにアペンドすることができ、関連していないトランザクションは異なるシャードに並列にアペンドすることができる。関連していないトランザクションを並列にアペンドする機能により、シャード化された台帳を、本質的によりスケーラブルなものであるとみなすことができる。さらに、各シャードは、利用できるリソースのサブセットによって管理することができる。１つの台帳（またはシャード化された台帳の場合は個々のシャード）を管理するために使用されるコンセンサス機構は、スケーリングが参加者の数にともなって悪化することが多いので、このようにシャード間でリソースを分割することは、個々のシャード各々のスループットを高めることにもなり得る。複数のシャードに対してトランザクションを並列にアペンドするという利点と個々のシャードのスループットを高めるという利点とを組み合わせることにより、結果として、同一のリソースセットが管理するモノリシック台帳と比較して、実質的にスループットを改善することができる。

単純に、完全に互いに独立している台帳のセットを作成しリソースを割り当てることにより各々を管理することには、本明細書に記載のシャード化された許可型の分散型台帳が共有しないいくつかの短所がある。たとえば、台帳と、完全に独立した台帳のセットを管理するリソースとの間の、固定されたマッピングは、柔軟性を欠き、一般的に、台帳間の自動負荷平衡を排除する。さらに、独立した各台帳を管理するリソースのセットがスタティックな状態のままであった場合、たとえば台帳の履歴の変更に同意することにより、台帳を腐敗させる可能性がある十分な数のこれらリソース間の連携が形成される可能性があるかもしれない。

いくつかの実施形態において、シャード化された許可型の分散型台帳は、シャードと、これらのシャードを管理するリソースとの間のマッピングを、動的に変更し得る。これは、いくつかの実施形態において、たとえば負荷平衡を実施する一般ポリシーを可能にすることができ、また、システムがリソースを定期的に再割り当てすることを可能にすることにより、場合によっては所定のシャードを管理するリソース間の連携を形成するための労力を混乱させる。加えて、１つのシャードの状態に関する情報を、他の１つ以上のシャードの台帳に含めることができる。１つのシャードの状態に関する情報を別のシャードの台帳に含めることは、以下でより詳細に説明するように、所定のシャードを腐敗させることを潜在的に一層困難にする「エンタングルメント（entanglement)」技術の一例とみなすことができる。

いくつかの実施形態において、シャード化された許可型の分散型台帳はまた、シャード間トランザクション（すなわち複数のシャードの状態に影響するまたは依存するトランザクション）をサポートする機会を提供し得る。

加えて、各種実施形態に従うと、本明細書に記載の方法、技術および／または機構は、さまざまなブロックチェーンおよび分散型台帳システムに適用可能であろう。

シャード化された許可型の分散型台帳の実現
先に述べたように、いくつかの実施形態に従うと、本明細書に記載の方法、技術および／または機構は、１つの台帳を管理するためにすべてのノードを相互に通信させるのではなく、１つの台帳を複数のシャードに分割しノードのサブセットに配置することによって各台帳を管理する。図１は、一実施形態に係る、シャード化された許可型の分散型台帳を実現するように構成されたシステムを示す論理ブロック図である。

いくつかの実施形態において、シャード化された許可型の分散型台帳は、完全なシャード化された許可型の分散型台帳を全体として表し得る複数のシャードを含み得る。加えて、１つのシャードはそれ自体が台帳であってもよい。言い換えると、情報のサブセットが台帳全体に含まれるが、１つのシャードは、完全な台帳と同じように機能およびやり取りすることができる。

システムのような、シャード化された許可型の分散型台帳を実現するように構成されたシステムは、台帳システム全体の参加者とみなし得る、ノード１２０Ａ～Ｎ等の複数のノードを含み得る。各種実施形態に従うと、ノード１２０Ａ～Ｎは、１つ以上のアプリケーション、モジュール、プロセス、スレッドなどを介して、たとえばディスパッチャ１３０Ａ～Ｎ、メンバシップ代表１４０Ａ～Ｎ、およびベリファイア１５０Ａ～Ｎを介して、台帳システムに参加するように構成することができる。加えて、いくつかの実施形態において、ノード１２０Ａ～Ｎは、複数のシャードに分割し得る、シャード化された許可型の分散型台帳を全体として管理するように構成することができる。

クライアント１８０Ａ～Ｍ等のクライアントは、ネットワーク１１０を介して通信することにより、シャード化された許可型の分散型台帳システムとやり取りする、たとえば台帳に追加するトランザクションを提示することができる。各種実施形態に従うと、ネットワーク１１０は、事実上任意の種類の通信媒体を介し事実上任意の通信プロトコルに従って動作する、事実上任意の種類の有線または無線ネットワークを表し得る。加えて、いくつかの実施形態において、各ノード１２０は、クライアントからのメッセージをベリファイアに導く役割を担うことができる、ディスパッチャ１３０Ａ～Ｎ等の１つ以上の特別の「ディスパッチャ」プロセスを有し得る。ノードごとに１つだけディスパッチャ１３０が示されているが、いくつかの実施形態において、各ノードが複数のディスパッチャを含む場合もある。

このシステムは、いくつかの実施形態において、台帳システムの実行中に利用される各種判断に関する情報を決定するおよび／または分配するように構成された、メンバシップおよび構成サービス１７０を含み得る。上記判断は、たとえば、任意の時点においてどのシャード上のどのノードがアクティブであるか、ストレージサービスが格納すべき各シャードのデータのコピーはいくつであるか、シャードに対してアクティブになる前に参加者（たとえばノード）が準備すべき事前通知はどれだけか、などの判断であり、詳細は以下で説明する。１つのエンティティとして示されているが、メンバシップサービス１７０は、いくつかの実施形態において、メンバシップ用、（たとえばシャードに対する）ノード割り当て用、システム構成用などの、複数のサービスを表し得る。

いくつかの実施形態において、このシステムはまた、台帳における（および／または台帳に対応付けられた）すべてのデータ（たとえばトランザクション）のうちの一部を管理するように構成されたストレージサービス１９０を含み得る。ノード１２０にシャードのデータに対する責任だけを負わせるのではなく、独立したストレージデバイス１９０を利用してもよく、詳細は後に説明する。いくつかの実施形態において、シャードはノード１２０Ａ～Ｎ上に格納されてもよいが、他の実施形態において、システムのシャード（と、したがって台帳と）は、ノード１２０Ａ～Ｎとは別に、ノード１２０Ａ～Ｎと異なるストレージデバイス上に、たとえばストレージデバイス１９０に、格納することができる。その他の実施形態において、シャードのデータは、ノード１２０Ａ～Ｎと、別のストレージデバイス、たとえばストレージデバイス１９０との両方に、格納してもよい。

複数のクライアント、たとえばクライアント１８０Ａ～Ｍは、たとえば台帳に追加するトランザクションをサブミットするために、シャード化された許可型の分散型台帳システムとやり取りすることができる。クライアント１８０が台帳システムに対してトランザクションを提示するとき、このクライアントは、このトランザクションを導く先であるシャード（すなわち台帳を構成するシャードのうちの１つ）を指定することができる。クライアント１８０は、さまざまなやり方のうちのいずれかで、ターゲットシャード（すなわちトランザクションを導く先であるシャード）を示すことができる。たとえば、一実施形態において、クライアント１８０と台帳システムとの通信を媒介する通信プロトコルは、クライアント１８０がターゲットシャードを示すことを媒介する機構（たとえばメッセージタイプ、フィールドなど）を提供し得る。加えて、トランザクションを、さまざまなやり方のうちのいずれかでシャードに割り当てることができ、これらのやり方は、サーバに対する負荷を平衡させる割り当て、地理的に近くにあるサーバを優先する割り当て、および／または関連するトランザクションを１つのシャードに集約させる割り当てを含むが、これらに限定されない。一般的に、シャードに対してトランザクションを割り当てるために使用される特定のやり方および／または機構は、実施形態によって異なり得る。

システム組織および信用モデル
先に述べたように、各シャードは、単一台帳システムと同様に管理し得る台帳として組織することができる。たとえば、一実施形態において、任意のノード１２０を割り当てることにより任意のシャードを管理することができる。しかしながら、他の実施形態において、ノード１２０Ａ～Ｎのサブセットのみが、任意の時点でいずれかの所定のシャードを管理できるようにしてもよい（たとえばスケーラビリティのため等）。本明細書には、シャード化された許可型の分散型台帳を実現するシステム内で、どの時点でどのシャードの管理にどのノードが参加するかを判断するさまざまな技術が記載される。

シャード化された許可型の分散型台帳は、台帳を妨害しようとするまたは腐敗させようとする敵から保護することができる。説明し易くするために、各ノードを１つのエンティティの制御下にあるとみなすことができる。また、さらに、敵は個々のノードの粒度で腐敗する可能性があると想定することができる。たとえば、あるノードの１つのプロセスが腐敗すると、そのノードのすべてのプロセスが不正をはたらくことになる。逆に、１つのノード上の複数のプロセスは互いを信用しているが異なる別々のノード上のプロセスは互いを信用していないとみなしてもよい。

本明細書では、各ノードがシャードごとに１つのベリファイアプロセスを有するシステムという観点で説明しているが、いくつかの実施形態において、シャード化された許可型の分散台帳システムを、各ノードがシャードごとにスレッドを有し得るように実現してもよい。さらに他の実施形態において、プロセスおよび／またはスレッドは異なる時点で異なるシャードを管理してもよい。よって、いくつかの実施形態において、シャード化された許可型の分散型台帳システムは、ノード１２０Ａ～Ｎ等の複数のノードを含み得る。各ノードはシャードごとにベリファイア１５０Ａ～Ｎ等のプロセスを含み得る。加えて、各ベリファイア１５０は、自身がそれに対してアクティブであるシャードのみの管理に参加してもよい。

図２は、一実施形態に係るシャード化された許可型の分散型台帳のシャードの管理に参加するベリファイアを示す論理図である。図２に示されているのは、いくつかの実施形態において、ノード１２０Ａ～Ｎのうちの個々のノードと同一の（または個々のノードを表す）ノード２１０、２２０および２３０である。なお、説明を容易にするために３つのノードのみが示されているが、いくつかの実施形態において、本明細書に記載のシャード化された許可型の分散型台帳システムには多数のノードが含まれ当該システムに参加してもよい。加えて、図示されていないが、ノード２１０、２２０および２３０は、ディスパッチャ、メンバシップ代表などのようなその他のアプリケーション、モジュール、プロセスおよび／またはスレッドを含み得る。

いずれかの所定の時点で、ノードは所定のシャードに対してアクティブまたは非アクティブである可能性がある。ベリファイアからシャードまでの点線で示されているように、あるノードが所定のシャードに対してアクティブである場合、そのノードの、そのシャードに対するベリファイアプロセスは、このシャードの台帳に新たなトランザクションをアペンドするコンセンサスに参加する。たとえば、ベリファイア２１５Ａからシャード２６５Ａまでの点線で示されるようにノード２１０のベリファイア２１５Ａがシャード２６５Ａに対してアクティブである場合がある。同様に、ベリファイア２１５Ｎからシャード２６５Ｓまでの点線で示されるようにベリファイア２１５Ｎがシャード２６５Ｓに対してアクティブである場合がある。加えて、ノード２２０のベリファイア２２５Ａ～Ｎおよびノード２３０のベリファイア２３５Ａ～Ｎのうちの各種ベリファイアは、ベリファイアからシャードまでの点線で示されるように、シャード２６５Ａ～Ｓのうちの対応するシャードに対してアクティブである場合がある。なお、図示のベリファイアとシャードとの論理的配置は、説明を容易にするためのものであって、ノード、ベリファイアおよび／またはシャードの実際の物理的配置を表しているのではないことに、注意されたい。

シャードを管理するとき、この所定のシャードに対するアクティブなベリファイアは、さまざまな方策および／またはコンセンサスプロトコルのうちのいずれかに従い得る。たとえば、一実施形態において、ノード２１０、２２０および２３０（および／またはノード１２０Ａ～Ｎ）のベリファイアは、ビザンチン行動に対する耐性を有するように「硬化」させることができるＲａｆｔのバージョン（本明細書ではＢＦＴ Ｒａｆｔと呼ぶ場合がある）に基づくコンセンサスアルゴリズムに従い得る。よって、いくつかの実施形態において、ベリファイアは、以下のうちの１つ以上のような各種方策を含むコンセンサスプロトコル（またはアルゴリズム）に従い得る。
・すべてのメッセージが送信者によって署名されて認証を可能にすることが必要である。
・一連のトランザクションのインクリメンタルハッシュを含み、ノードが全トランザクションシーケンスについて合意することを確認することを可能にし、他にとって明らかにならないよう台帳の履歴を改訂することを事実上不可能にする。
・リーダーだけでなくすべての参加者に確認をブロードキャストする。

これらの方策は結果としてＯ（ｎ^２）のメッセージの複雑さをもたらし得るものの、このようなコンセンサスプロトコルは、より多くの数のノードにスケーリングすることができ、より高いトランザクションスループットを達成することができる（たとえば異なるノードがそれぞれ異なるレートで進行することを可能にするからである）。

加えて、いくつかの実施形態において、シャード化された許可型の分散型台帳システムは、リーダー２４０等のリーダーベリファイアを含み得る。リーダー２４０は台帳にアペンドする新たなトランザクションを提案することができる。

図３は、シャード化された許可型の分散型台帳にトランザクションを追加する方法の一実施形態を示すフローチャートである。ブロック３００に示されるように、リーダー２４０は、提案されたトランザクションをこの台帳のシャードに追加すると判断することができる。各種実施形態に従うと、リーダー２４０は、各種方法のうちのいずれか、たとえば、クライアントがサブミットしたトランザクションを受けることにより、提案するトランザクションを決定することができる。ブロック３１０のように、リーダー２４０は、台帳にアペンドする新たなトランザクションの提案を、提案されたトランザクションおよびサポート情報（たとえばリーダーの権限および／または真正性）を他のアクティブベリファイアに送信することにより、行うことができる。たとえば、いくつかの実施形態において、リーダーは、リーダーとしての妥当性を示す投票を表示する（または表す）情報、新たなトランザクションをアペンドする場所の前にある台帳インデックスなどを含むサポート情報を利用することができる。ブロック３２０のように、提案されるトランザクションを受けたベリファイアは、当該トランザクションおよびサポート情報が有効であることを確かめることができる。判断ブロック３３０の肯定出力が示すように、サポート情報（および／または提案されるトランザクションの他の側面）が有効である場合、ブロック３４０に示されるように、ベリファイアはこの事実の確認を発行することができる。（たとえばトランザクションに対するターゲットシャードに対してアクティブである、および／または提案されたトランザクションを受ける）各ベリファイアは、リーダー２４０からの、提案されたトランザクションおよび／またはサポート情報を独立して検証し、確認を発行することができる。いくつかの実施形態において、リーダー２４０はまた、（たとえば他のベリファイアと一致する）確認を公開してもよいが、その他の実施形態において提案されるトランザクションの送信は、リーダー２４０による確認を表し得る。

いくつかの実施形態において、判断ブロック３５０の肯定出力およびブロック３６０に示されるように、ノードは、特定数のアクティブなベリファイアから確認を受けると、提案されたトランザクションはコミットされたとみなすことができる。したがって、ノードは、定数のアクティブなベリファイアから、台帳内の所定のインデックスにおけるトランザクションについての確認を受けると、そのインデックスまでのトランザクションはコミットされたとみなしてもよい。加えて、いくつかの実施形態において、より低いインデックスにおけるすべてのトランザクションもコミットされたとみなすことができる。

いくつかの実施形態に従うと、定数は、シャード上のアクティブノードの過半数とみなすことができる。図２は１シャード当たり２つのアクティブベリファイアのみを示しているが（すなわち図示および説明を容易にするために）、その他の実施形態において、１シャード当たり奇数のベリファイアを用いて、明確な大多数に達するようにしてもよい。したがって、定数のアクティブノードが、提案されたトランザクションを、台帳内の次のトランザクションとして確認すると、（少なくとも１つのアクティブベリファイアが、詐欺である決定的なプルーフを提供する、矛盾する確認に署名しない限り）別の定数がそのインデックスにおける異なるトランザクションを確認することは不可能となり得る。

いくつかの実施形態において、現在のリーダーが不正をはたらいた場合または反応しなくなった場合、定数のアクティブベリファイアは、リーダーを辞任させて新たなリーダーを選ぶことができる。定数のベリファイアによって辞任させられると、元のリーダーの任期が終了したとみなされ、別の、新たなリーダーの任期が始まる。

シャードに対するトランザクションの追加に関連するメッセージの複雑さは、システム内のノードの総数に応じて決まるのではなく、そのシャードに対するアクティブノードの数に応じて決まると考えることができる。いくつかの実施形態に従うと、これは、複数のシャードが並列に動作することを可能にし、さらに、各シャードが、すべてのノードによって管理される１つのシャードのスループットよりも高いスループットを実現できるようにする。

ディスパッチャ
先に述べたように、各ノードは、クライアントからアクティブベリファイアにメッセージを導く役割を担うことができる、ディスパッチャ１３０Ａ～Ｎ等の１つ以上のディスパッチャプロセスを有し得る。図４は、受信メッセージをディスパッチする方法の一実施形態を示すフローチャートである。ブロック４００のように、ディスパッチャ１３０は、ターゲットシャードを示すクライアントからのメッセージを受信することができる。いくつかの実施形態において、ディスパッチャ１３０Ａ～Ｎは、クライアント１８０Ａ～Ｍからトランザクション要求を受けることができる。クライアントからの要求は、ターゲットシャードと、コマンドおよび／またはトランザクション（たとえばターゲットシャードに追加／適用する、提案されたトランザクション）とを、指定することができる。ディスパッチャは、ターゲットシャードに対してアクティブであるベリファイア１５０等のプロセスに対し、受信した要求を転送する役割を担うことができる。判断ブロック４１０の肯定出力が示すように、ディスパッチャと同じノード（たとえばディスパッチャが実行しているノード）上のベリファイアがターゲットシャードに対してアクティブである（たとえばターゲットシャードを管理する役割を担う）場合、ブロック４２０のように、ディスパッチャはこの要求をディスパッチャ自身のノード上のプロセス（たとえばベリファイア）に転送することができる。

判断ブロック４１０の否定出力が示すように、ディスパッチャと同じノード上に、ターゲットシャードに対してアクティブであるベリファイアがない場合、ブロック４３０のように、ディスパッチャは、ターゲットシャードに対してアクティブである別のノード（すなわちディスパッチャ自身のノードから離れている）上のプロセス（たとえばベリファイア）に要求を送ることができる。いくつかの実施形態において、アクティブなベリファイアへのすべての要求の転送においてディスパッチャが完璧に正確である必要はない場合がある。それでもなお、できるかぎり頻繁にそうすることによって不必要な転送は避けることができる。

いくつかの実施形態において、ディスパッチャは、ターゲットシャードに対してアクティブであるプロセスの識別をサポートするために状態情報を管理することができる。いくつかの実施形態において、ディスパッチャが管理するこの状態情報は、少なくとも、所定のシャードを管理するベリファイア等のプロセスのセット、そのシャードに対して現在アクティブであるプロセスのサブセット、および／またはそのシャードを管理するディスパッチャ自身のノード上のプロセスのアイデンティティを、含み得る。各種実施形態に従うと、シャード化された許可型の分散型台帳を実現するように構成されたシステムは、各種やり方のうちのいずれかで、プロセス、ベリファイアおよび／またはシャードを識別することができる。たとえば、一実施形態において、固有の識別子を各プロセス、ベリファイア、シャードなどに対応付けてもよく、これらの識別子（名称、数値ＩＤ、英数字ＩＤなど）を状態情報内で利用してもよい。その他の実施形態において、ポインタ（たとえばプログラマティックメモリポインタ）を用いて、プロセス、ベリファイア、シャードなどを識別する、その位置を求める、および／またはそれと通信することができる。

ディスパッチャは、ターゲットシャードに対してアクティブであるローカルプロセスがある場合は、状態情報を用いて要求をローカルに転送することができる。ターゲットシャードに対してアクティブであるローカルプロセスがない場合、ディスパッチャは、状態情報を用いて、ターゲットシャードに対してアクティブである遠隔プロセスを識別することができる。いくつかの実施形態において状態情報はディスパッチャ自身のノード上でローカルに管理することができ、他の実施形態においてディスパッチャは遠隔の場所に格納されている（がアクセス可能である）状態情報に依拠することができる。各種実施形態に従うと、アクティブなベリファイアおよびシャードに関する状態情報は、メンバシップサービスからのディレクティブに応じて更新することができる。

シャード割当
いくつかの実施形態において、各シャードに対するアクティブプロセスは、初期化時間において判断することができ、システムの寿命にわたってスタティックなままであってもよい。しかしながら、いくつかの実施形態において、スタティックプロセス割当の使用には、以下のようないくつかの短所がある場合がある。
・シャードの追加を認めない。
・ノードの追加を認めない。
・シャードに対するアクティブな参加者の交替を認めない（たとえば役目を果たさなくなるまたは不正をはたらいていることが観察される場合）。
・常に所定のシャードに対して同一ノードセットがアクティブなままであり、所定のシャードを管理する不正ノード間の連携が発生する可能性を許す。

他の実施形態において、ノード（および／またはベリファイア）をシャードに対して動的に割り当てることができる。

各種実施形態において、いつプロセスがそのシャードに対してアクティブになるかを判断するためにさまざまな仕組みを用いることができる。たとえば、いくつかの実施形態において、ベリファイア等のプロセスは、シャードに対するアクティベーションの固定されたスケジュールに従うことができる。たとえば、所定のシャードに対してアクティブであるベリファイアは、そのシャードの台帳が特定の長さに達した場合／とき、そのシャードに対して非アクティブになる場合がある。しかしながら、いくつかの実施形態において、非アクティブなプロセス／ベリファイアは、条件（台帳が特定の長さに達する等）がそれを要求しないときは直ちにアクティブになることができない場合がある。なぜなら、これらの条件に気が付かない場合があるからである。代わりに、いくつかの実施形態において、プロセス／ベリファイアが「起こされ」、所定のシャードに対して現時点でアクティブであることを知らされてもよい。いくつかの実施形態において、起こすプロセスは、そのシャードに対してまもなく非アクティブになるプロセス等の別のアクティブプロセスが実行してもよい。他の実施形態において、ディスパッチャに、その状態情報を更新させプロセスを目覚めさせるおよび／または現時点でアクティブであることをプロセスに通知することができる関連イベント（しきい値長さに達するシャード等）を通知してもよい。また、新たにアクティブになったプロセスは、シャードがしきい値長さ（たとえばプロセスがアクティブになることをトリガするしきい値）に達したことを知っているシャードに対してアクティブである別のプロセスからメッセージを受信することによって起こされてもよい。さらに他の実施形態において、メンバシップサービス１７０の参加者により、プロセスが、シャードに対してアクティブになったことを知らされてもよい。

固定されたスケジュールで（たとえば台帳が特定数のトランザクションに達したときに）プロセス／ベリファイアをアクティブにする代わりに、いくつかの実施形態では、プロセス／ベリファイアが、以下の情報、すなわち
・シャードに対する負荷に関する情報、
・そのシャードに対してアクティブであるプロセスの可用性および反応性に関する情報、
・そのシャードに対してアクティブであるプロセスの（疑われる）不正に関する情報、および
・サービスレベル要件、制約などのようなポリシー入力に関する情報、
のうちのいずれかまたはすべてを含む各種情報の組み合わせの影響を受ける可能性がある定期的な再割り当てに基づいてアクティブ／非アクティブになってもよい。

いくつかの実施形態において、参加者（たとえばノード、プロセス、ベリファイアなど）がシャード割当を制御できないことは重要であろう。そうでなければ、ノードのグループが共謀して、シャード（このシャード内の他のすべてのアクティブ参加者に得票数で勝つことができる）への十分なアクティブ参加を実現することにより、（たとえば私利的におよび／または不法目的のために）そのシャードを制御する能力を有効に獲得することができるかもしれない。これが理由で、いくつかの実施形態において、シャード割当判断は、場合によっては追加情報とともに、参加者が制御できないランダム（たとえば疑似ランダム）シーケンスの決定的関数として実現されるポリシーにより、推進されてもよい。

シャード割当判断に対してランダム情報を使用することにより、敵（たとえば不正をはたらくノード）が、１つ以上のシャードの支配権を獲得することを可能にし得る選択を一貫して行うことを防止することができ、責任追跡性を提供することもできる。たとえば、決定論的ポリシーおよびランダムネスソースによって指図された選択から逸脱しようとする試みを検出することができ（すなわち直ちにまたは事後に）、不正ノードの責任追跡性を保つことができる。

一般的に、ランダムネスソース、たとえば暗号ランダムネスソースは、決定論的シャード割当ポリシーに対し、各種のやり方のうちのいずれかで、利用することができる。各種実施形態に従うと、いくつかの例は以下を含む。
・周期的にシャードをランダムに選択し、そのシャードに対してアクティブな１つのプロセスを選択し、これを非アクティブにした後で、同じノードのプロセスがそれに対して非アクティブであるシャードをランダムに選択し、これをアクティブにするポリシー、
・繰り返し２つのシャードをランダムに選択し、その後、異なるシャードに対してアクティブであるノードのペアを選択し、これらの役割を入れ替えるポリシー、および／または
・所望のどのようなポリシーにも適合する新たなシステムワイドの割当を周期的に生成するポリシー（たとえば各シャードが十分なアクティブプロセスを有することおよびノード全体に負荷が均等に平衡であることを保証する）。

上記ポリシーの第１の例は、それに対して所定のノードがアクティブであるシャードの数を一定に保つ一方で、アクティブなシャード割当において何らかの転換（または「解約（churn）」）を生じさせることができる。しかしながら、いくつかの実施形態において、これは、進歩し各シャードに対する特定数のビザンチンノードに耐えるのに十分なアクティブノードを各シャードが常に有することを保証しないかもしれない。上記ポリシーの第２の例は、各ノードに対する負荷および１シャード当たりのアクティブプロセスの数を保存することができる。

一般的に、各種実施形態に従うと、特定の目的に最も有効であるポリシーの選択に影響を与え得るトレードオフ、課題および／または制約が存在し得る。たとえば、再割り当てが十分に頻繁でなければ、所定のシャードに参加するノードは連携を形成する機会を有することができ、そのシャードの支配権を得ようとすることができる。一方、いくつかの実施形態において、シャードに対する再割当プロセスは、さまざまなオーバヘッドを伴い得る。たとえば、いくつかの実施形態において、プロセスは、あるシャードに対して非アクティブである場合、最近のトランザクションに関する最新情報を持つことはなく、新たなトランザクションのアペンドに参加できるようになる前に通信してこの情報を得る必要があるかもしれない。したがって、プロセスを過剰に頻繁に再割り当てすることは望ましくない場合がある。

シャード再割当の数および頻度等のパラメータは実施形態によって異なり得る。たとえば、一実施形態において、このようなパラメータは初期化時間パラメータによって決定することができ、他の実施形態において、このようなパラメータは、シャードに対する観察された負荷（たとえばトランザクションの数）および／または責任追跡性情報、たとえば、シャードに対するしきい値数のアクティブ参加者が、別のアクティブ参加者が反応がないまたは不正をはたらいたことをいつ報告するか等の、各種入力に基づいて、変化し得る。

まもなくアクティブになるプロセスの準備
より多くのトランザクションをシャードに追加するためのコンセンサスに参加するために、ノード上のアクティブプロセスは、そのシャードに対する以前のトランザクションの最新情報を持っていなければならないであろう。これは、このノードが、以前のすべてのトランザクションの文脈においてトランザクションの妥当性を確認できるようにするために、必要であろう。加えて、いくつかの実施形態において、アクティブプロセスは、新たなトランザクションを構成するときに（たとえば台帳の耐タンパー性を保証するのに役立つようにするために）最新トランザクションの暗号ハッシュを使用できるよう、最新でなければならないであろう。プロセスが過去に非アクティブであった場合、このプロセスは、シャード（それに対してプロセスが現在アクティブである）に対するいくつかまたはすべてのトランザクションを欠いている場合がある。

各種実施形態において、参加者（たとえばベリファイア）は、いくつかの方策のうちのいずれかに従い、最新になることができる。たとえば、いくつかの実施形態において、コンセンサスアルゴリズム（たとえばＢＦＴ Ｒａｆｔコンセンサスアルゴリズム等）は、後方の参加者が遥か前方の他の参加者に「追い着く」ためのプロビジョンを有し得る。しかしながら、とりわけ、ノードがあるシャードに対して長時間非アクティブであった場合、（追い着こうとしながら）参加者が必要なすべてのトランザクションを取得している間に、相当な遅延が生じる可能性がある。

これに代えて、他の実施形態において、ベリファイ可能なシャード「スナップショット」がさまざまなポイントにおけるシャードの状態を要約することにより、新たにアクティブになったベリファイアがそのシャードに対するすべてのトランザクションをリプレイしなくてもスナップショットを採用することを場合によっては可能にする。なぜなら、これはシャード上で最後のアクティブなものであるからである（または、ベリファイアが過去にこのシャードについてアクティブになったことがない場合はシャードに対するすべてのトランザクション）。一実施形態において、参加者は、スナップショットの妥当性確認および署名を行い、十分な数の参加者がスナップショットの妥当性確認および署名を行った場合は、これらのうちの少なくとも１つが正当であることを保証できる。

図５は、ベリファイアがアクティブになったときにシャードスナップショットを利用する方法の一実施形態を示すフローチャートである。ブロック５００のように、ベリファイアが所定のシャードに対してアクティブになったときに、ブロック５１０の否定出力が示すようにベリファイアがシャードに対して最新でない場合（通常はそうであろう）、ベリファイアはこの所定のシャードに対してスナップショットを利用できるか否かを判断することができる。たとえば、スナップショットが所定のシャードに対して生成される前にベリファイアはアクティブになっているので、利用できるスナップショットはない場合がある。ブロック５２０の否定出力が示すようにシャードに対してスナップショットを利用できない場合、ブロック５６０のようにベリファイアはシャード台帳に対して前のトランザクションをリプレイすることができる。各種実施形態に従うと、シャード台帳に対してトランザクションをリプレイするとき、ベリファイアは、各種のやり方のうちのいずれかで、たとえば、必要とする、最近アクティブになったベリファイアまたはストレージサービス１９０からの追加のトランザクションデータを要求することによって、トランザクションを取得することができる。他の実施形態において、トランザクションまたはスナップショットデータは、その他のベリファイアおよび／または参加者（ストレージサービスの参加者等）が、ベリファイアがアクティブになった（またはアクティブになるであろう）ことを観察したことに応じて、事前に送信してもよい。

代わりに、判断ブロック５２０の肯定出力が示すように利用できるスナップショットがある場合、ブロック５３０のように、ベリファイアはシャードに対するこのスナップショットを取得し認証することができる。各種実施形態に従うと、ベリファイアは、各種のやり方のうちのいずれかで、スナップショットを取得する、またはスナップショットにアクセスすることができる。一実施形態において、スナップショット（またはスナップショットのコピー）は、ベリファイア自身のノードに格納することができる。他の実施形態において、ベリファイアは、遠隔ノードからの、またはストレージデバイス１９０からのスナップショットを要求および／またはスナップショットにアクセスするように構成し得る。

加えて、いくつかの実施形態に従うと、ベリファイアは、たとえば少なくとも特定数の他の参加者がスナップショットの妥当性を確認しスナップショットに署名したことをチェックすることにより、スナップショットを認証することができる。いくつかの実施形態において、「エビデンス」をトランザクションまたはスナップショットデータとともに格納することにより、受け手がその正確さをベリファイすることを可能にしてもよい。このようなエビデンスは、トランザクションまたはスナップショットが有効であることを受信ベリファイアがチェックできるようにする、トランザクションもしくはスナップショット、暗号ハッシュおよび／またはマークルプルーフ（Merkle proof）に対して投票したベリファイアの署名を含み得る。そうすると、ブロック５４０のように、ベリファイアは、スナップショットからトランザクションを適用することができる。

判断ブロック５５０の肯定出力が示すように、スナップショットに含まれないシャードに対するその他の（追加の）トランザクションがある場合、ブロック５６０のように、ベリファイアはシャードからのこれらのトランザクションをリプレイすることができる。たとえば、追加のトランザクションは、ベリファイアがスナップショットを取得し使用している間にシャードにコミットされているであろう。

先に述べたように、スナップショットという方策は、追い着くのに必要な時間を短縮するかもしれないが、それを完全になくすことはできない。なぜなら、スナップショットの取得および妥当性確認には時間がかかる可能性があり、新たなトランザクションの追加への参加を開始するのに十分ベリファイアが追いつく前に、スナップショット後に適用するトランザクションが存在し得るからである。したがって、いくつかの実施形態において、シャード化された許可型の分散型台帳を実現するように構成されたシステムは、近い将来シャードに対してアクティブになるであろうという事前の警告をプロセス／ベリファイアに与えるように、構成することができる。よって、いくつかの実施形態において、あるプロセスは、所定のシャードに対してアクティブになることを要求される前に、追い着き始めることができるであろう。たとえば、ベリファイアは、最近アクティブになったベリファイアから、またはストレージデバイス１９０から、必要な追加トランザクションデータを要求することができる
いくつかの実施形態において、将来の参加者が遠過ぎることが予めわかっている場合、悪意のある連携が形成される機会が発生する可能性がある。一方、与えられる通知が不十分である場合、参加を開始するのに必要なデータを新たにアクティブになったノード／ベリファイアが取得する間に（たとえば追い着く間に）遅延が発生している可能性がある。一般的に、与えられる通知の量は実施形態によって異なり得る。各種実施形態に従うと、たとえば、与えられる通知の量は、初期化時間パラメータに基づく、および／または観察（たとえば、アクティブな参加の開始前にノードが追い着くために要する長さ等）に基づいて動的に適合化／調整される可能性がある。

ストレージ
従来のモノリシックなブロックチェーンシステムにおいて、すべての参加者は、すべてのトランザクションおよび関連するメタデータ（たとえばブロック、ブロックヘッダ、スナップショットなど）を受信し、その妥当性を確認し、格納することができる。いくつかの実施形態において、シャード化された許可型の分散型台帳システムでは、アクティブでないベリファイアはトランザクションの最新記録を保持していない可能性があり、そうすると、先に述べたように、これらのベリファイアが再びアクティブになったときには、追い着く間に遅延がある可能性がある。他の実施形態において、非アクティブノードおよび／またはベリファイアは、コンセンサスの完了後に（たとえば、トランザクションがシャードにコミットされたときに）アクティブノードにトランザクションをブロードキャストさせることにより、最新状態を保つことができる。このような実施形態において、アクティブノードは、コンセンサスプロセスの一部として他のアクティブ参加者から受けた署名された（たとえば認証された）メッセージを格納することができる。

加えて、いくつかの実施形態に従うと、アクティブでないベリファイアにブロードキャストされるトランザクションは、その時点でアクティブであった参加者間でコンセンサスが得られたというプルーフを伴い得る。よって、いくつかの実施形態において、すべてのノードはすべてのシャードの（少なくとも比較的）最新の情報を保持している可能性があり、一方で、コンセンサスに関連する通信を、全参加者よりも少ない参加者を含み得るアクティブな参加者のグループに限定する。しかしながら、アクティブでないベリファイアに対して事前にブロードキャストすると、結果としてストレージおよび処理オーバヘッドが追加され、たとえばすべてのノードがすべてのシャードに対するすべてのトランザクションを格納しそれに対して少なくとも何等かの処理を実行していることになるであろう。

アクティブでないベリファイアへのブロードキャストによって生じる追加のオーバヘッドの量を減じるために、それに対して所定のノードがアクティブになる可能性があるシャードのセットは制限されてもよい。たとえば、あるノードは、特定のシャードセットの外部のシャードには決して参加せずしたがってそれらのトランザクション（たとえば特定のセットに含まれないシャードに対するトランザクション）を格納および処理する必要は決してないであろう。いくつかの実施形態において、ノードを特定のシャードに限定することは、多数のノードおよび多数のシャードを有する大型ネットワークにおいては望ましいであろう。そうすると、所定のシャードに参加するために利用できる十分なノードがあり、共謀の試みを打ち砕く通常の再割り当てを可能にする。

加えて、いくつかの実施形態において、個々のノードに、専らシャードデータの格納および（たとえばノードがシャードに追い着くことを容易にするスナップショットに対する）要求への応答という役割を担わせるのではなく、ストレージデバイス１９０等の別個のストレージサービスを用いてもよい。シャードを管理するノードと同様に、ストレージサービスへの参加者が、許可されてもよく、利用できることおよび／または格納することを要請されていたデータを提供できることについて、責任追跡性を保つことができる。

いくつかの実施形態において、非アクティブになったシャードベリファイアは、先ず、シャードに関するデータ（たとえばトランザクション、コンセンサス、および／またはその他のデータ）がストレージサービス１０９において十分利用できるようにされることを保証することが求められる可能性がある。たとえば、ベリファイアは、ストレージサービス１９０の１つ以上のストレージノードにこのデータを送信するように構成することができる。加えて、いくつかの実施形態において、ベリファイアはまた、このデータが格納されたという署名付きの確認を受信する（および／または認証する）ように構成することができる。いくつかの実施形態において、（たとえば別個のストレージサービス１９０を用いて）ストレージを処理から切り離すことは、データを十分な回数レプリケートすることにより利用できるようになる見込みを高める一方で、過剰な要求（たとえばすべての参加者にすべてのデータを格納させる等）を場合によっては避けることを可能にする。

各種実施形態に従うと、シャード化された許可型の分散型台帳システムのその他の構成可能な側面と同様に、ストレージサービスが格納すべきデータのコピーの数等のパラメータは、初期化時間パラメータによって決定されてもよく、または、参加者からおよび／または認可されたアドミニストレータからの入力によって通知された決定論的ポリシーによって駆動される、動的なパラメータであってもよい。これらおよびその他の入力を収集し使用する１つのやり方は、以下で説明する特別の「コーディネーションシャード」を介するやり方であってもよい。

メンバシップおよび構成サービス
先に述べたように、各種実施形態に従うと、シャード化された許可型の分散型台帳システムは、さまざまな構成および／または動作に関する判断を行うように構成することができる。この判断は、たとえば、所定の時点でどのシャードに対しどのノードがアクティブであるかに関する、（たとえばストレージサービスが）格納すべき各シャードのデータのコピーの数に関する、および／または参加者がシャードに対してアクティブになることを要求される前に受信すべき事前通知の量等に関する判断である。各種シナリオおよび実施形態においてその他多くの可能な種類の判断が関連し得る。いくつかの実施形態において、シャード化された許可型の分散型台帳システムは、このような判断を行うように構成されたメンバシップサービス１７０を含み得る。いくつかの実施形態において、メンバシップサービス１７０は、メンバシップサービス、アクティブノードをシャードに割り当てるためのサービス、および／または構成サービス等の、複数のサービスに分解することができる。よって、異なる実施形態に従うと、メンバシップサービス１７０は、本明細書では１つのサービスとして記載されているが、複数の異なる（が場合によっては相互に関連がある）サービスを含み得るおよび／または表し得る。

ノードは、さまざまなやり方でメンバシップサービス１７０とインターフェイスすることができる。たとえば、一実施形態において、各ノードは、メンバシップサービス１７０に参加するように構成されディスパッチャおよび／またはベリファイア等の、そのノードにおける他のプロセスと通信し得る、特別の「メンバシップ代表」プロセス１４０を含み得る。いくつかの実施形態において、メンバシップサービス１７０は、（たとえばノードから分離された）別個のモジュールを表していなくてもよく、代わりに、メンバシップサービス１７０は、複数のノードの複数のメンバシップ代表１４０が集合的に提供するサービスを表していてもよい。

各種実施形態に従うと、一般的に、各種機構のうちのいずれかを利用して、メンバシップサービスを実現する、メンバシップサービスと通信する、および／またはメンバシップサービスに参加することができる。たとえば、本明細書では独立したモジュール／として示され説明されているが、一実施形態ではノードを代表するディスパッチャおよびメンバシップの役割を組み合わせて１つのプロセスにしてもよい。

各種実施形態に従うと、メンバシップサービス１７０は、メンバシップ、どのノードがどのシャードに対してアクティブかについての割り当て、および／またはその他のシステム構成変更に関する、さまざまな判断を行うように構成することができる。メンバシップ代表は、これらの判断に基づいて、指令をディスパッチャおよび／またはベリファイア等のその他の参加者に伝えることができる。たとえば、いくつかの実施形態において、メンバシップ代表１４０は、指令を、関連する指令をベリファイアに転送するように構成することができるディスパッチャに伝えるように、構成することができる。

いくつかの実施形態において、メンバシップサービスの重要な要件は、正当なすべての参加者が同じ判断シーケンス（したがってその結果生じる指令）を観察することであろう。たとえば、一実施形態において、決定論的スケジュール（たとえば初期化時間に固定）に従ってもよい。しかしながら、このような固定された決定論的スケジュールは、不正をはたらくまたは反応しなくなったノード等の、特定のイベントに対しては反応できないかもしれない。別の実施形態において、反応しないこと、不正行為、構成変更などの報告のような入力およびイベントに基づいて判断を行う決定論的ポリシーを用いることができる。

いくつかの実施形態において、メンバシップサービス１７０はコーディネーションシャードを含み得る。これは、システム内の他のシャードのための技術と同様の技術を用いて実現し得る。図６は、一実施形態に係るメンバシップサービスをコーディネーションシャードとともにを示す論理図である。たとえば、メンバシップサービス１７０はコーディネーションシャード６１０を含み得る。コーディネーションシャード６１０は、メンバシップ／シャード情報６３０等の関連する入力およびイベントを記録する（たとえばそうすることによってすべて正当な参加者が入力およびイベントの同じビューを持つようにする）ことにより、コーディネーションシャード６１０の参加者が、たとえば場合によってはこれらの入力およびイベントを入力として採用する決定論的ポリシーに基づいて、メンバシップディレクティブ６２０を伝えられるように、構成し得る。

一例として、各シャードに対する１のアクティブな参加者を、そのシャードに対するＴのトランザクションの完了ごとに、入れ替えることにより、どのシャードに対してどのノードがアクティブであるかを判断するための単純な仕組みについて考える。そのために、コーディネーションシャード６１０に、いつシャード２６５等のシャードｓがＴのトランザクションを完了したかを知らせることができる。これは、シャードｓに対してアクティブであるベリファイア１５０等の参加者によってコーディネーションシャード６１０にサブミットされるトランザクション６４０を介して行われてもよい。これに代えて、ベリファイア１５０が、そのローカルな（したがって信頼される）ディスパッチャ１３０にシャード２６５の進行を知らせてもよく、ディスパッチャ１３０は、関連イベントをメンバシップサービス１７０に伝えてもよい（そうするとメンバシップサービス１７０はイベントをコーディネーションシャードにサブミットすることができる）。加えて、いくつかの実施形態において、ディスパッチャ１３０はトランザクション６４０を通信シャード６１０にサブミットしてもよく、他の実施形態において、ディスパッチャ１３０はローカルメンバシップ代表と通信してもよく、そうするとローカルメンバシップ代表はメンバシップ／シャード情報６３０をメンバシップサービス１７０および／またはコーディネーションシャード６１０に伝えてもよい。いくつかの実施形態において、トランザクション６４０は、シャード２６５がＴ以上のトランザクションをコミットしたという表示を含んでいてもよく、また、トランザクションがコミットされたエビデンスとしてノードの１つ以上の投票が現在アクティブであるという表示を含んでいてもよい。

いくつかの実施形態において、追加情報がたとえばトランザクションを介してコーディネーションシャード６１０にサブミットされてもよい。このような追加情報は、限定されないが、以下を含む。
・他のノードの挙動に関する観察。これは、反応性がないこと、明らかにプロトコルに違反するように実施していること、および／または、直接的に不正行為を実証する訳ではないが注目すべきやり方で実施していることを含む。
・シャードの負荷（たとえば直近のＴのトランザクションにかかる時間）に関する観察。
・状態情報のサマリー（たとえば、場合によっては、簡潔で偽造不可能なサマリー）。これはたとえば、シャードの特定のインデックスまでのトランザクションの正味効果、またはメンバシップサービスもしくはその他のサービスから受けた指令のストリームの場合と同様のものである。これらは以下でより詳細に説明する「エンタングルメント」の例とみなし得る。
・パラメータを調整するための、特別に認証されたパーティからの指令。たとえば、コンソーシアムの統治委員会の５メンバーのうちの３メンバーが署名したトランザクションであり、これは、そのシャードに対するトランザクションがストレージサービスによって少なくとも３回レプリケートされねばならないことを示す。
・システムの参加者を追加または解任するための、特別に認証されたパーティからの指令。
・不正をはたらいたと思われる参加者に対してペナルティを課すための、特別に認証されたパーティからの指令（おそらく一部はコーディネーションシャードに以前含まれていた観察に基づく）。

いくつかの実施形態において、どのような間隔でどのシャードに対してどの参加者がアクティブであるか等の情報を含む、所定の時点におけるシステムの現在の構成（たとえばある参加者は、シャードに対して、そのシャードに対するトランザクションＮからトランザクションＮ＋Ｔまで、アクティブであり得る）は、コーディネーションシャードの台帳における情報の、決定論的関数であってもよく、またはこの情報に基づいていてもよい。よって、特定数の正当なノードがコーディネーションシャードの台帳の状態に同意する場合／とき、これらはシステムの構成について得られた共通のビューを有するとみなすことができる。

コーディネーションシャード６１０に参加し得るプロセスおよび／またはプロセスの数は、実施形態によって異なり得る。一実施形態において、たとえば構成変更が十分にまれである場合に、すべてのベリファイアおよびディスパッチャが参加してもよい。その他の実施形態において各ノードのディスパッチャが参加してもよく、その他の実施形態においてディスパッチャのアクティブなサブセットのみが参加してもよい。いくつかの実施形態に従うと、アクティブな割り当て、またはコーディネーションシャードに対してどのプロセスがアクティブであり得るかは、通常のシャードに対して実現されるやり方と同様に、判断されてもよい。一般的に、コーディネーションシャードへの参加のためにプロセスを割り当てる（プロセスがアクティブになる）やり方は、実施形態によって異なり得るものであり、変更の頻度、必要な反応性の程度、脅威のレベルなどといったさまざまな要素に応じて決まり得る。

いくつかの実施形態において、コーディネーションシャード６１０に対してコミットされたトランザクションは、すべてのメンバシップ代表（および／またはディスパッチャ）にブロードキャストされねばならないであろう。たとえば、利用できるすべての正当なノードが、たとえばコーディネーションシャードに維持されているかもしれない、最新のメンバシップおよび構成情報を有していることを保証することが必要であろう。加えて、いくつかの実施形態において、システム全体のさまざまな側面の制御におけるコーディネーションシャードの潜在的な重要性を考慮すると、通常のシャード（たとえばシャード２６５）のアクティブな参加者よりも多数のコーディネーションシャード６１０のアクティブな参加者を有することが望ましいであろう。他の構成パラメータと同様、コーディネーションシャードのアクティブな参加者の数および／またはコーディネーションシャードにサブミットされるトランザクションの頻度を含むトレードオフは、実施形態によって異なり得る。たとえば、コーディネーションシャードに関連する構成パラメータは、初期化時に固定されてもよく、動的に適合させ／調整してもよい（たとえばコーディネーションシャードに記録される入力およびイベントに対して作用する決定論的ポリシーを介して）。

加えて、いくつかの実施形態において、コーディネーションシャードの役割は複数の特別シャードによって実現されてもよい。たとえば、ある特別シャードはどのエンティティがシステムへの参加を認可されるかを判断してもよく、別の特別シャードはどのノードがどのシャードに対してアクティブかを判断してもよく、別の特別シャードはアクティブメンバシップの変更が発生する前にシャードにコミットされるべきトランザクションの数等の構成パラメータを管理する。各種実施形態に従うと、一般的にコーディネーションシャードはさまざまなやり方のうちのいずれかで実現し得る。

エンタングルメント
本明細書に記載のエンタングルメントは、シャード化された許可型の分散型台帳システムをより腐敗しにくくする技術とみなすことができる。たとえば、エンタングルメントは、ある場所からの情報の簡潔で偽造不可能なサマリーを、別の場所に含めることを含み得る。たとえば、台帳に記録されるときにトランザクション（またはトランザクションのブロック）に含まれる暗号ハッシュは、エンタングルメントの１つの基本形態とみなすことができる。暗号ハッシュは、台帳上の１ブロックまたはトランザクションの内容の変更を、続くすべてのブロックまたはトランザクションも変更することなく、行うことを、不可能にする（たとえば、各トランザクションは前のトランザクションの暗号ハッシュに基づいている可能性があるためである）。

各種実施形態に従うと、エンタングルメントはこの基本形態を超える他のさまざまなやり方で使用することができる。たとえば、一実施形態において、あるシャードにサブミットされたトランザクションは、別のシャードの現在または最近の状態（たとえば状態情報）の暗号ハッシュを含むことにより、たとえある連携が第２のシャードの履歴を改訂できるようにするのに十分に第２のシャードを支配しようとしても、これは第１のシャードに含まれるハッシュによって第２のシャードはもはや正確に要約されないことを立証することなどにより、検出可能である（および／または照明可能である）ことを、場合によっては保証することができる。その軌跡をカバーするために、あるシャードを改訂しようと試みる連携は、改定すべきデータのサマリーを記録した１つ以上の他のシャードを支配し改訂することも必要であろう。複数の他のシャードに対する通常のエンタングルメントを保証することにより、たとえシャードの支配に成功する連携であっても、シャードの内容を検出されずに改訂することは極めて困難である。

よって、いくつかの実施形態において、ベリファイアが、シャードの現在の状態の暗号ハッシュを計算、判断、または取得するように構成されてもよく、さらにトランザクションを別のシャードにサブミットするときにその暗号ハッシュを含むように構成されてもよい。

別の例において、一実施形態では、コーディネーションシャード（たとえばメンバシップサービスを実現するために使用されるシャード）にサブミットされるトランザクションは、追加情報を、たとえば暗号ハッシュまたは別のシャードの状態の表現のマークルルート（Merkle root）を、含み得る。このようなエンタングルメントは、複数の通常シャード間のエンタングルメントと同様の利点、および／または追加の利点（たとえば、コーディネーションシャードが、システム内におけるその重要な役割のために、より大きな定数サイズ、精査などを有する場合）を有するとみなし得る。

さらに別の例において、メンバシップサービス１７０がその他の参加者（ディスパッチャ１３０および／またはベリファイア１５０など）に送る指令のストリームは、場合によっては通常のシャードに対する各トランザクションとともに含まれるハッシュと同様であるかもしれない、累積ハッシュ（たとえば指令のストリームにおけるすべての情報のハッシュ）を含み得る。したがって、これらのハッシュは、場合によってはこの指令のストリームが腐敗させられることなく受信されたエビデンスとして、メンバシップサービス１７０に報告され（たとえばコーディネーションシャード６１０に）記録されてもよい。いくつかの実施形態において、報告されたハッシュにおけるいずれのミスマッチも、直ちに問題を提起し得るものであり、不正をはたらいている可能性がある参加者を特定することができる。いくつかの実施形態に従うと、逆に、参加者のうちの一部、大部分、またはすべてから受けた、マッチするハッシュは、メンバシップサービス１７０が発行した指令について、不一致または曖昧さがないという信頼を高めると考えられる。

いくつかの実施形態において、エンタングルメントは定期的に必要となり得るものであり、実現されるエンタングルメントの正確な性質は、コーディネーションシャード６１０が実現するポリシーによって推進することができる。先に述べたように、ある参加者がエンタングルメント要件に従わないことにより、フラグが立てられる、調査が引き起こされる、および／または疑わしい参加者によるさらなる参加などが防止される。加えて、いくつかの実施形態に従うと、メンバシップサービス指令のサマリーは、複数のパーティを必要とし得る。たとえば、一実施形態において、指令はディスパッチャ１３０に送信されてもよく、関連する指令はディスパッチャ１３０からローカルベリファイア１５０に転送されてもよく、これらのベリファイア１５０はコーディネーションシャード６１０にトランザクションを（直接または間接的に）サブミットすることにより、指令が腐敗させられていない（たとえばトランジットにおいておよび／または中間参加者のいずれかによって）ことを場合によっては証明する。いくつかの実施形態において、シャードごとのサマリーをメンバシップサービス１７０およびベリファイア１５０が計算することで、ベリファイア１５０が自身のシャードに対する指令しか受けないかもしれない場合でも、ベリファイアの状態の妥当性確認が可能である。

責任追跡性および信用
先に述べたように、シャード化された許可型の分散型台帳への参加は、許可のみによるものであってもよい。したがって、許可付与は、参加者が不正をはたらいた場合に備えて参加者の責任追跡性を保つ機会を生み出すことができる。たとえば、いくつかの実施形態において、そのシャードに対してアクティブにされていない不正ノードがどうしてもシャードのコンセンサスに投票しようと試みた場合、これは、不正行為を証明できるかもしれない他のノードによって検出される場合がある（たとえば、コンセンサスラウンドの署名された投票を、送信者がそのラウンドのシャードに対してアクティブにされなかったというプルーフとともに、示すことによって）。結果として、システムにより、および／または既存の機構により、法的ペナルティ、訴訟などのペナルティが自動的に課される場合がある。よって、ノードは、プロトコル（たとえばシステムが実現するコンセンサスプロトコル）に従う、または、特に証明できるのであれば、検出できる何らかの不正行為を少なくとも回避する、強い動機を有し得る。

いくつかの実施形態において、アクティブな正当シャード参加者は、たとえば、アクティブである振りをする腐敗した非アクティブ参加者からのメッセージを正当参加者が無視できるよう、他のどのシャード参加者がアクティブであるかを見分けることができなければならない。たとえば、いくつかの実施形態において、正当ノードのアクティブベリファイアは、少なくとも、所定のトランザクションインデックスにおいてアクティブであるノードのサブセットがわかっているであろう。そうでなければ、腐敗したノードのセットが、参加することを認められることなく、シャードのコンセンサスプロトコルにおける定数を形成するのに足りる投票を送ることにより、シャードを乗っ取る可能性がある。先に述べたように、メンバシップサービス１７０は、限定されないが特別なコーディネーションシャード６１０、決定論的スケジュール、またはその他の機構を含む、各種実施形態に係るさまざまなやり方で、実現することができる。さらに、いくつかの実施形態において、メンバシップサービス１７０は、すべての正当なメンバシップ代表が同じ指令シーケンスを対応するディスパッチャ１３０および／またはベリファイア１５０に伝えることを保証するように、構成することができる。

たとえば、ベリファイアｖ１が、インデックス１，５００におけるトランザクションについて、ベリファイアｖ２から投票を受けた場合、ベリファイアｖ１は、ベリファイアｖ２がそのインデックスにおいてアクティブであることを示す命令をメンバシップサービスが発行したと判断した後に、インデックス１，５００におけるベリファイアｖ２の投票をカウントすることができる。いくつかの実施形態に従うと、ベリファイアｖ１がそのような命令を入手できない場合、ベリファイアｖ１は、ベリファイアｖ２がそのインデックスにおいてアクティブであるという確認を受けるまで、その投票のカウントを延期するように、構成されてもよい。

いくつかの実施形態において、ベリファイアｖ２は、アクティブであることを求めるその要求を支持する「エビデンス」を提供することが求められる場合がある。たとえば、メンバシップサービス指令は「命令シーケンス番号」を含むことができ、ベリファイアｖ２はその投票とともに、１，５００を含む間隔に対してそれをアクティブにする指令のシーケンス番号を含み得る。その後ベリファイアｖ１がメンバシップサービス命令をそのシーケンス番号とともに受けたとき、ベリファイアｖ１は、この指令が実際ベリファイアｖ２をインデックス１，５００を含む間隔に対してアクティブにすることを確認することができ、そうでなければ、ベリファイアｖ１は、その投票とともに無効なエビデンスを提供することによって、ベリファイアｖ２が不正をはたらいたという警告を発することができる。いくつかの実施形態において、各投票とともに指令のシーケンス番号を含めることは、無効な証拠がそのように特定される前の時間の問題にすぎないことを保証し、よって、そのような不正行為を阻止することができる。

他の実施形態に係るより精巧な仕組みは、指定された指令を待つことなくベリファイアｖ１が要求を確認できるようにし得るより多くのエビデンスを含み得る。たとえば、一実施形態において、このエビデンスは、メンバシップサービス１７０が下した判断のシーケンスが示唆する状態が、トランザクションインデックス１，５００におけるそのシャードに対してベリファイアｖ２がアクティブであることを反映することを示す、マークルプルーフを含み得る。これは、ベリファイアｖ１が、そのプルーフをチェックすることを可能にするとともに、メンバシップサービスからの追加の指令を待つことなくベリファイアｖ２の要求を確認することができる。

しかしながら、このような手法は多くの場合不必要であるかもしれない。先に述べたように、参加者がアクティブになる前に少なくとも何らかの事前通知を受けていることが望ましい。その場合、上記の状況、すなわち、ベリファイアｖ２が投票するときまでベリファイアｖ２がアクティブになるという判断にベリファイアｖ１がまだ気付いていないという状況は、比較的まれであるかもしれない。最悪の場合とは、（その時点において）ベリファイアｖ１がベリファイアｖ２の投票をカウントすることができない場合である。いくつかの実施形態に従うと、不正なノードの数および／または遅延している指令の数に応じて、これは潜在的に、より多くの指令を受けるまでトランザクションを受け入れるために十分な投票をノードが確認することを妨げる可能性がある。

いくつかの実施形態において、たとえばベリファイアｖ２は自身が偽っていれば将来発見され場合によってはぺナルディが課されるおよび／またはそうでなければ責任追跡性を保たれることが、わかっているので、ベリファイアｖ２がアクティブであることを求める要求を、ベリファイアｖ１は文字通り受け入れることができる。いくつかの実施形態において、構成パラメータは、このような「投機的」投票がいくつカウントされ得るかを判断することができる。しかしながら、いくつかの実施形態において、１つの投機的投票をカウントした場合でも、定数の正当にアクティブなノードの投票なしで、不正な投票によりトランザクションが確認される場合がある。いくつかの実施形態において、これは全く受け入れられないかもしれず、したがって、投票を、その送信者が正当にアクティブであることをベリファイする前にカウントしないように、ノードを構成してもよい。

各種実施形態に従うと、そのようなベリフィケーションは、遅延した指令が到着するのを単に待つこと以外のやり方で、実現することが可能である。たとえば、一実施形態において、エビデンスを（たとえばストレージサービス１９０によっておよび／またはメンバシップサービス１７０の参加者によって）格納することにより、場合によっては、エビデンスをオンデマンドで要求できるようにすることが可能である。よって、いくつかの実施形態において、上記例に従い、ベリファイアｖ２は、その署名された投票とともに、それがアクティブであることを証明するエビデンスの識別子（たとえばハッシュ）を含んでいてもよく、ベリファイアｖ１は、ｖ２の要求をベリファイするためにこのエビデンスを要求するように構成されてもよい。

その他詳細および／または最適化
いくつかの実施形態において、（たとえばディスパッチャがそのメンバシップ代表から受ける指令等の）データのクエリを、それがベリファイされおよび／または信用されるソースから受けられた後に最適化するための各種技術のうちのいずれかを使用するように、参加者が構成されてもよい。たとえば、一実施形態において、ディスパッチャは、各々がノード、シャード、および間隔（たとえば開始、終了）を特定するMakeActive指令のストリームを受けることができる。各指令がベリファイされると（たとえば、最低、それを送信した信用されるローカルメンバシップ代表の署名をベリファイ／認証することによって）、その指令は、ローカルデータ構造に格納することができる。このような指令をローカル格納することにより、共通動作のスピードを改善することができる。いくつかの実施形態において、ベリファイアは、たとえばその共通動作を容易にするために、（たとえばローカルディスパッチャまたはメンバシップ代表から）指令を受けたときに適切なデータ構造を同様に更新するように、構成されてもよい。

いくつかの実施形態において、アクティブベリファイアは、そのシャードに対する現在のトランザクションインデックスにおいて他のどのベリファイアがアクティブであるかを判断するように構成されてもよく、また、コンセンサスに関連するメッセージをそれらにブロードキャストするように構成されてもよい。加えて、別のベリファイアからコンセンサスに関連するメッセージ（たとえばトランザクションに対する投票等）を受けると、アクティブベリファイアは、受信者の現在のインデックスとは同一でない可能性がある、この投票が特定するトランザクションインデックスに対し、送信者がアクティブであることを確認するように、構成されてもよい。

いくつかの実施形態において、現在のトランザクションに対してどのベリファイアがアクティブであるかという判断に関連し、かつ、特定のトランザクションインデックスに対して送信者がアクティブであるという確認に関連するクエリは、受けた各命令に対する「間隔マップ」を更新することにより、サポートすることができる。いくつかの実施形態において、間隔マップは、キーが間隔であるキーと値のマップをサポートすることができ、クエリは、特定された間隔などと重なる、特定されたポイントを含む間隔に対応付けられているのはどの値かを判断することができる。いくつかの実施形態において、間隔マップは間隔ツリーを用いて実現することができる。

引続き上記例において、ベリファイアｖ１は、間隔マップを保持するように構成されてもよく、さらに、（値の）ペアを、間隔［１０００，２０００］をベリファイアｖ２を特定する記録にマッピングするその間隔マップに挿入するように構成されてもよい。データを間隔マップに挿入するとき、ベリファイアｖ１はまた、ベリファイアｖ２のパブリックキー等の、必要になる見込みがあるその他の情報を含み得る（このような情報は他の場所で入手できる可能性があるが、これを間隔マップに格納することにより、頻繁にアクセスされる情報へのアクセスを高速化することができる）。いくつかの実施形態に従うと、間隔マップを保持することにより、ベリファイアｖ１は、投票を受けたインデックスで、間隔マップをクエリすることができ、それにより、場合によっては、そのインデックスにおいてアクティブであるベリファイアのセットを識別する。

他の最適化は当業者にとって明らかであろう。たとえば、いくつかの実施形態において、ベリファイアは、一度だけその現在のトランザクションインデックスについて間隔マップをクエリし、そのインデックスについてのコンセンサス関連のメッセージを処理するときに繰り返し使用するために結果をキャッシュするように、構成されてもよく、新たな指令がこの結果に影響する場合に備えて、キャッシュされた結果を無効にするかまたは更新する。その他の実施形態において、このような最適化は、たとえば関数の結果を記憶する関数型言語で実現されるので、「無料」になる場合がある。

いくつかの実施形態に従うと、ディスパッチャも同様に、その共通動作を高速化するためにデータ構造を保持してもよい。たとえば、ディスパッチャは、ベリファイアのための上記間隔マップと同様の、シャードごとの間隔マップを保持するように構成されてもよい。しかしながら、先に述べたように、ディスパッチャの主な役割は、クライアントからトランザクションを受けて適切なベリファイアに送ることであろう。いくつかの実施形態において、ディスパッチャは、各シャードに対してどのベリファイアがアクティブであるかに関する正確な情報を有する（または取得する）必要はない。たとえば、ディスパッチャ１３０が、現在アクティブではないというメッセージ（たとえばクライアントトランザクション）をベリファイア１５０に送った場合に、ベリファイア１５０はそのメッセージをローカルディスパッチャ１３９に転送するように構成されてもよい。

しかしながら、いくつかの実施形態において、パフォーマンスのためには、ディスパッチャがシャードに対するアクティブなベリファイアを特定することが望ましい場合がある。さらに、ディスパッチャがメッセージをアクティブではないベリファイアに対して繰り返し送る場合、これらのベリファイアは上記メッセージをディスパッチャに送り返してもよく、台帳における全体の進行は低速になるかもしれない。よって、いくつかの実施形態において、ベリファイアは、そのシャード上で見た最も高いトランザクションインデックスをディスパッチャに（たとえば定期的に）知らせることにより、ディスパッチャがその間隔マップをクエリすることを場合によっては可能にし、どのベリファイアが現在アクティブであるかを（たとえば妥当な正確性を伴って）場合によっては判断できるように、構成されてもよい。

ランダムネス
先に述べたように、いくつかの実施形態に従うと、どの時点でどのシャードに対しどの参加者がアクティブであるかを求めるための、および、さまざまな構成パラメータの現在の値を求めるための、ポリシーおよび／または判断は、少なくとも一部、ランダムな選択に基づき得る。よって、いくつかの実施形態において、このようなポリシーが決定論的でありいずれかの参加者が独立して計算できることを保証するために、共有される、ランダムネスのソースが必要であろう。ポリシーの結果の操作を避けるために、誰も（たとえばどのノードも、またはどの他の参加者も）、ランダムネスソースを制御できないようにしなければならない。さらに、敵が前もって計画する機会を打ち消すために、使用するいずれのランダムデータも、必要なときよりも長時間前に知られてはならない。したがって、いくつかの実施形態において、初期化時にランダムシード（seed）を選択しそれを永遠に使用することは十分ではない場合がある。代わりに、いくつかの実施形態において、シャード化された許可型の分散型台帳システムは、シャード化されたランダムネスソースを定期的に交換するように構成されてもよい。

いくつかの実施形態において、ランダムネスソースは、コーディネーションシャードに対するリーダーの任期の間使用されてもよく、次のリーダーの任期のために新たなランダムネスソースに交換されてもよい。たとえば、一実施形態に従い、決定論的疑似ランダム数生成器の新たなシードが、各リーダーの任期ごとに生成されてもよい。しかしながら、各種実施形態に従い本明細書で説明するように、一般的に、ランダムネスを提供するための各種機構のうちのいずれかを、シャード化された許可型の分散型台帳を実現するときに利用してもよい。加えて、各種実施形態に従い、ランダムネスソースは、より高い頻度で（より高いセキュリティを提供）またはより低い頻度で（必要な作業が少ない）更新されてもよく、（たとえばリーダーに基づくコンセンサスを使用しないシステムのような）リーダーシップ変更以外のイベントによって推進されてもよい。

たとえば、いくつかの実施形態において先に述べたように、ランダムネスは、決定論的疑似ランダム数生成器の「良好な」シードを生成することによって生成することができる。明らかに、シードの選択をいずれかの参加者が制御可能であってはならない。加えて、いくつかの実施形態において、シードは予め相当前に予測可能でなくてよい。シャードのベリファイアのうちのいずれが遠い将来においてアクティブにされるかを敵が前もって見分けることができる場合、敵は、これらのベリファイアを腐敗させようとして作業を始めることができる。

一実施形態において、リーダーの任期が終了すると、リーダーは、前もって予測されないかもしれないコミットされた最後のトランザクションの暗号ハッシュを取るように構成されてもよい。しかしながら、このハッシュはリーダーによって操作されるかもしれない。たとえば、不正なリーダーは、たとえば腐敗させようとするシャードに「友好的な」参加者を割り当てるなど、生成されたハッシュが所望のプロパティを有するように、トランザクションを選択しオーダーすることができる。したがって、いくつかの実施形態において、現在のランダムネスソースは、仲間（buddy）ノードを各リーダーに決定論的に割り当てる。その任期の終了時に、リーダーは、この仲間ノードを、コミットされた最後のトランザクションのインクリメンタルハッシュに送ることができ、仲間ノードは、そのプライベートキーでハッシュに署名し署名されたハッシュをリーダーに返すように構成されてもよく、リーダーはそうすると、自身の署名で結果をＸＯＲし、そうすると、どのパーティーにも制御されないシードが得られる。

加えて、いくつかの実施形態において、リーダーに複数の仲間ノード（たとえば、システムが許容し得る腐敗ノードと少なくとも同数）を割り当ててもよい。割り当てられた数のノードだけが腐敗すると仮定すると、これにより、少なくとも１つ（リーダーまたは仲間のうちの１つ）が正当でありしたがって「トライアル・アンド・エラー」共謀に加わることはないことを、保証することができる。いくつかの実施形態に従うと、ランダムシードがすべての署名の関数（たとえばこれらすべてのＸＯＲ）によって選択された場合、１参加者が正当であることを保証することは、ランダムネスソースを制御する誰をも除外することになる。

いくつかの実施形態において、リーダーまたはその仲間のうちのいいずれかがこのプロトコルに参加しない場合、リーダーは最終的に退けられるかもしれず、新たなリーダーが選ばれる。そうすると、新たなリーダーは、同様のプロトコルに参加することにより、その１または複数の仲間（前のランダムネスソースの関数によって決まる）と協働して新たなランダムシードを生成することができる。いくつかの実施形態において、最終的に、その仲間がすべて反応し少なくとも１の仲間が正当であるリーダーが見出される見込みが高く、これは、新たな信頼できるランダムネスソースが生成されプロトコルを通常に進めることができることを意味する。

上記手法は、結果として得られたランダムネスをリーダーが気に入らない場合に備えてリーダーが失敗する振りをすることができるようにするが、これは、次のリーダーおよびその仲間が選択するランダムネスに何の影響も及ぼさないであろう。さらに、この失敗は、他から見えるものであるため、この失敗が結果を故意に操作しようとする試みであると疑われる場合に備えて評価できるエビデンスに寄与し得る。

コンピューティングシステムの一例
本明細書に記載の、シャード化された許可型の分散型台帳システムを提供するための技術および方法の実施形態のさまざまなコンポーネントは、その他さまざまなデバイスとやり取りし得る１つ以上のコンピュータシステムまたはコンピューティングデバイス上で実行することができる。１つのこのようなコンピュータシステムまたはコンピューティングデバイスを図７に示す。示されている実施形態において、コンピュータシステム１０００は、入出力（Ｉ／Ｏ）インターフェイス１０３０を介してシステムメモリ１０２０に結合された１つ以上のプロセッサ１０１０を含む。コンピュータシステム１０００はさらに、Ｉ／Ｏインターフェイス１０３０に結合されたネットワークインターフェイス１０４０と、カーソルコントロールデバイス１０６０、キーボード１０７０、音声デバイス１０９０、およびディスプレイ１０８０等の１つ以上の入出力デバイス１０５０とを含む。いくつかの実施形態では、実施形態をコンピュータシステム１０００の１つのインスタンスを用いて実現することが意図されているが、他の実施形態では、複数のこのようなシステムまたはコンピュータシステム１０００を構成する複数のノードが、実施形態の異なる部分、コンポーネント、またはインスタンスをホストするように構成されてもよい。たとえば、一実施形態において、いくつかの要素は、他の要素を実現するノードとは異なるコンピュータシステム１０００の１つ以上のノードを介して実現されてもよい。

各種実施形態において、コンピュータシステム１０００は、１つのプロセッサ１０１０を含むユニプロセッサシステムであってもよく、または、いくつかのプロセッサ１０１０（たとえば２、４、８、または別の好適な数）を含むマルチプロセッサシステムであってもよい。プロセッサ１０１０は、命令を実行可能な任意の好適なプロセッサであればよい。たとえば、各種実施形態において、プロセッサ１０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ ＩＳＡ、またはその他好適なＩＳＡ等の、さまざまな命令セットアーキテクチャ（ＩＳＡ）のうちのいずれかを実現する、汎用または埋め込みプロセッサであってもよい。マルチプロセッサシステムにおいて、プロセッサ１０１０は各々、一般に、必然的にではないが、同じＩＳＡを実現し得る。

いくつかの実施形態において、少なくとも１つのプロセッサ１０１０はグラフィックス処理ユニットであってもよい。グラフィック処理ユニットまたはＧＰＵは、パーソナルコンピュータ、ワークステーション、ゲーム機またはその他のコンピュータシステムのための専用グラフィックレンダリングデバイスとみなされてもよい。現代のＧＰＵは、コンピュータグラフィックスの操作および表示において非常に効率が高い場合があり、その高度な並列構造が、これらを、グラフィカルアルゴリズムの範囲において典型的なＣＰＵよりも効果的にしている。たとえば、グラフィックプロセッサは、ホスト中央処理装置（ＣＰＵ）を用いて画面に直接描画するよりもはるかに速くこれらを実行するように、複数のグラフィック基本動作を実現することができる。ＧＰＵは、プログラマーがＧＰＵの機能を呼び出すことを許可する１つ以上のアプリケーションプログラマーインターフェイス（ＡＰＩ）を実現し得る。好適なＧＰＵは、ＮＶＩＤＩＡ社、ＡＴＩテクノロジーズ、およびその他等の販売業者から市販されているであろう。

システムメモリ１０２０は、プログラム命令および／またはプロセッサ１０１０からアクセス可能なデータを格納するように構成し得る。各種実施形態において、システムメモリ１０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプメモリ、または任意のその他の種類のメモリ等の任意の好適なメモリ技術を用いて実現し得る。示されている実施形態において、たとえば、図２～図６に示されるように送信側ノードおよび／または受信側ノードとして分散型台帳メッセージを処理するための方法を含むがこれらの方法に限定されない、分散型台帳の責任追跡性および信頼を高めるための方法の各種実施形態について先に述べたような、所望の機能を実現するプログラム命令およびデータは、システムメモリ１０２０に、プログラム命令１０２５およびデータストレージ１０３５としてそれぞれ格納されるものとして示されている。他の実施形態において、プログラム命令および／またはデータは、異なる種類のコンピュータアクセス可能媒体に、またはシステムメモリ１０２０またはコンピュータシステム１０００とは別の同様の媒体において、受信、送信、または格納されてもよい。一般的には、たとえば、コンピュータアクセス可能媒体は、Ｉ／Ｏインターフェイス１０３０を介してコンピュータシステム１０００に結合されたディスクまたはＣＤ／ＤＶＤ－ＲＯＭである、磁気または工学媒体等の、ストレージ媒体またはメモリ媒体を含み得る。コンピュータアクセス可能媒体を介して格納されるプログラム命令およびデータは、たとえばネットワークインターフェイス１０４０を介して実現し得る、ネットワークおよび／または無線リンク等の通信媒体を介して変換し得る、電気、電磁、またはデジタル信号等の送信媒体または信号によって、送信されてもよい。

一実施形態において、Ｉ／Ｏインターフェイス１０３０は、ネットワークインターフェイス１０４０、または入出力デバイス１０４０等の他の周辺インターフェイスを含む、デバイス内の任意の周辺デバイスと、システムメモリ１０２０と、プロセッサ１０１０との間のＩ／Ｏトラフィックを調整するように構成し得る。いくつかの実施形態において、Ｉ／Ｏインターフェイス１０３０は、あるコンポーネント（たとえばシステムメモリ１０２０）からのデータ信号を、別のコンポーネント（たとえばプロセッサ１０１０）が使用するのに適したフォーマットに変換するために、任意の必要なプロトコル、タイミングまたはその他のデータ変換を実行し得る。いくつかの実施形態において、Ｉ／Ｏインターフェイス１０３０は、たとえば、周辺コンポーネント相互接続（ＰＣＩ）バス標準規格またはユニバーサルシリアルバス（ＵＳＢ）標準規格の変形等の、各種の周辺バスを通して装着されたデバイスに対するサポートを含み得る。いくつかの実施形態において、Ｉ／Ｏインターフェイス１０３０の機能を、たとえばノースブリッジおよびサウスブリッジ等の２つ以上の別々のコンポーネントに分割してもよい。加えて、いくつかの実施形態において、システムメモリ１０２０へのインターフェイス等のＩ／Ｏインターフェイス１０３０の機能のうちの一部またはすべてを直接プロセッサ１０１０に組み込んでもよい。

ネットワークインターフェイス１０４０は、コンピュータシステム１０００と、その他のコンピュータシステム等の、ネットワークに装着されたその他のデバイスとの間で、または、コンピュータシステム１０００のノード間で、データをやり取りできるように構成し得る。各種実施形態において、ネットワークインターフェイス１０４０は、たとえば任意の好適な種類のイーサネット（登録商標）ネットワーク等の無線または有線汎用データネットワークを介して、アナログ音声ネットワークもしくはデジタルファイバー通信ネットワーク等の電気通信／電話ネットワークを介して、ファイバーチャネルＳＡＮ等のストレージエリアネットワークを介して、または、任意の他の好適な種類のネットワークおよび／またはプロトコルを介して、通信をサポートし得る。

入出力デバイス１０５０は、いくつかの実施形態において、１つ以上の表示端末、キーボード、キーパッド、タッチパッド、スキャンデバイス、音声もしくは光認識デバイス、または１つ以上のコンピュータシステム１００によって入力または取り出すのに適した任意の他のデバイスを、含み得る。複数の入出力デバイス１０５０がコンピュータシステム１０００内にあってもよく、コンピュータシステム１０００の各種ノード上に分散されていてもよい。いくつかの実施形態において、同様の入出力デバイスが、コンピュータシステム１０００から分離されていてもよく、有線または無線接続を介して、たとえばネットワークインターフェイス１０４０を介して、コンピュータシステム１０００の１つ以上のノードとおやり取りしてもよい。

図７に示されるように、メモリ１０２０は、分散型台帳の責任追跡性および信頼を高めるための方法の実施形態を実現するように構成されたプログラム命令１０２５と、プログラム命令１０２５からアクセス可能な各種データを含むデータストレージ１０３５とを含み得る。一実施形態において、プログラム命令１０２５は、上記図面に示される、分散型台帳の責任追跡性および信頼を高めるための方法の実施形態のソフトウェア要素を含み得る。データストレージ１０３５は、実施形態で使用し得るデータを含み得る。その他の実施形態において、その他のまたは異なるソフトウェア要素およびデータが含まれていてもよい。

コンピュータシステム１０００は例示されているにすぎず本明細書に記載の分散型台帳の責任追跡性および信頼を高めるための方法の範囲を限定することを意図していないことを、当業者は理解するであろう。特に、コンピュータシステムおよびデバイスは、コンピュータ、ネットワークデバイス、インターネット機器、ＰＤＡ、無線電話、ポケットベルなどを含む、示された機能を実行できるハードウェアまたはソフトウェアの任意の組み合わせを含み得る。コンピュータシステム１０００は、図示されていないその他のデバイスに接続されてもよく、代わりにスタンドアロンシステムとして動作してもよい。加えて、示されているコンポーネントが提供する機能は、いくつかの実施形態において、より少ないコンポーネントになるように組み合わせれてもよく、その他のコンポーネントに分散されてもよい。同様に、いくつかの実施形態において、示されているコンポーネントのうちのいくつかの機能は提供されなくてもよく、および／またはその他の追加機能が利用できるようにされてもよい。

また、さまざまなアイテムは、使用中、メモリまたはストレージに格納されているものとして示されているが、これらのアイテムまたはその一部は、メモリ管理およびデータ完全性のために、メモリと他のストレージデバイスとの間で転送され得ることを、当業者は理解するであろう。これに代えて、その他の実施形態において、ソフトウェアコンポーネントのうちの一部またはそのすべてが、メモリにおいてまたは別のデバイス上で実行され、示されているコンピュータシステムと、コンピュータ間通信を介して通信してもよい。システムコンポーネントまたはデータ構造のうちの一部またはそのすべても、（たとえば命令または構造データとして）コンピュータアクセス可能媒体上に、または、その各種の例は先に述べた通りである、適切なドライブによって読み出されるポータブル商品上に、格納されてもよい。いくつかの実施形態において、コンピュータシステム１０００とは別のコンピュータアクセス可能媒体に格納される命令は、ネットワークおよび／または無線リンク等の通信媒体を介して伝達される、電気、電磁、またはデジタル信号等の信号または送信媒体を介して、コンピュータシステム１０００に送信されてもよい。各種実施形態はさらに、上記説明に従い実現される命令および／またはデータを、受信、送信、またはコンピュータアクセス可能媒体に格納することを含み得る。したがって、本発明は、その他のコンピュータシステム構成でも実施し得る。

図面に示され本明細書に記載されている各種方法は、方法の実施形態の例を表す。これらの方法は、ソフトウェア、ハードウェア、またはその組み合わせにおいて実現し得る。方法の順序は変更してもよく、各種要素の追加、再配置、組み合わせ、削除、修正などが可能である。

各種修正および変更は、本開示の恩恵を受ける当業者にとって明らかになるようにすることができる。本発明がこのような修正および変更をすべて包含し、したがって上記説明は制限的ものではなく例示的なものとみなされることが、意図されている。

Claims (15)

1. シャード化された許可型の分散型台帳システムであって、前記システムは、
   前記分散型台帳システムに複数のノードとして参加するように構成された複数のコンピューティングデバイスを備え、前記複数のノードは、１つ以上のトランザクションに関する情報を格納するように構成された複数の台帳シャードを含む分散型台帳を管理するように構成されており、
   各ノードは、
   前記複数の台帳シャードのうちの個々の台帳シャードに対して個々のトランザクションに関する情報をアペンドするためにコンセンサスプロトコルに従って参加するように構成された、１つ以上のベリファイアサービスと、
   ディスパッチャサービスとを含み、
   前記ディスパッチャサービスは、クライアントからトランザクション要求を受けるように構成されており、前記トランザクション要求は、特定のトランザクションと前記複数の台帳シャードのうちのターゲットシャードとを示す情報を含み、かつ
   前記ディスパッチャサービスは、前記受けたトランザクション要求を、前記ターゲットシャードに対応付けられた、前記ベリファイアサービスのうちの１つに転送するように構成されている、シャード化された許可型の分散型台帳システム。
2. 前記ベリファイアサービスは、前記転送された要求によって指定されるトランザクションに関する情報を、前記ターゲットシャードにアペンドするように構成されている、請求項１に記載のシャード化された許可型の分散型台帳システム。
3. 前記ディスパッチャサービスはさらに、前記受けたトランザクション要求を、前記ターゲットシャードに対応付けられたリーダーベリファイアに転送するように構成されており、
   前記リーダーベリファイアは、前記コンセンサスプロトコルに従い、前記ターゲットシャードに対応付けられた前記ベリファイアサービスに対して前記特定のトランザクションを提案するように構成されている、請求項１または２に記載のシャード化された許可型の分散型台帳システム。
4. 構成サービスをさらに備え、前記構成サービスは、各対応するノードごとに、前記複数の台帳シャードのうちの個々の台帳シャードに対してアクティブになる、前記対応するノード上の前記ベリファイアサービスのサブセットを決定するように構成され、所定の台帳シャードに対してアクティブであるベリファイアサービスが、コンセンサスに参加して新たなトランザクションを前記台帳シャードにアペンドする、請求項１から３のいずれか１項に記載のシャード化された許可型の分散型台帳システム。
5. 前記構成サービスはさらに、ランダムネスのシャード化ソースに少なくとも一部基づいて前記ベリファイアサービスのサブセットを決定するように構成されており、前記ランダムネスのシャード化ソースは、前記複数のノードが制御できないランダムデータを提供する、請求項４に記載のシャード化された許可型の分散型台帳システム。
6. 前記複数の台帳シャードのうちの個々の台帳シャードにアペンドされるトランザクションのカウント、
   前記台帳シャードのうちの１つ以上についての状態情報の暗号ハッシュ、および、
   前記台帳シャードのうちの個々の台帳シャードに対応付けられたベリファイアサービスに関する情報、
   のうちの１つ以上を記録するように構成された分散型構成台帳をさらに備える、請求項１から５のいずれか１項に記載のシャード化された許可型の分散型台帳システム。
7. 前記複数の台帳シャードに関する指令を前記ノードのうちの１つ以上にブロードキャストするように構成された構成サービスをさらに備える、請求項６に記載のシャード化された許可型の分散型台帳システム。
8. コンピュータが実施する方法であって、
   分散型台帳システムに複数のノードとして参加するように構成された複数のコンピューティングデバイス上で、１つ以上のトランザクションに関する情報を格納する複数の台帳シャードを含む分散型台帳を管理するステップと、
   前記ノードのうちの１つのノード上のディスパッチャプロセスが、クライアントからトランザクション要求を受けるステップとを含み、前記トランザクション要求は、特定のトランザクションと前記複数の台帳シャードのうちのターゲットシャードとを示す情報を含み、
   前記ディスパッチャプロセスが、前記受けたトランザクション要求を、前記ターゲットシャードに対応付けられたベリファイアプロセスに転送するステップを含み、前記ベリファイアプロセスは複数のベリファイアプロセスのうちの１つであり、前記複数のベリファイアプロセスは各々、前記複数の台帳シャードのうちの個々の台帳シャードに個々のトランザクションに関する情報をアペンドするためにコンセンサスプロトコルに従い１つ以上の他のベリファイアプロセスとともに参加するように構成されている、コンピュータが実施する方法。
9. 前記ベリファイアプロセスが、前記転送された要求によって指定されるトランザクションに関する情報を、前記ターゲットシャードにアペンドするステップをさらに含む、請求項８に記載のコンピュータが実施する方法。
10. 前記ターゲットシャードに対してアクティブである前記ベリファイアプロセスのセットの中からリーダーベリファイアを決定するステップをさらに含み、
    前記転送するステップは、前記ディスパッチャプロセスが、前記受けたトランザクション要求を、前記リーダーベリファイアに転送するステップを含み、
    前記リーダーベリファイアが、前記コンセンサスプロトコルに従い前記ターゲットシャードに対してアクティブである前記ベリファイアプロセスのセットに、前記特定のトランザクションを提案するステップをさらに含む、請求項８または９に記載のコンピュータが実施する方法。
11. 構成サービスが、各対応するノードごとに、前記複数の台帳シャードのうちの個々の台帳シャードに対してアクティブになる、前記対応するノード上の前記ベリファイアプロセスのサブセットを決定するステップをさらに含む、請求項８から１０のいずれか１項に記載のコンピュータが実施する方法。
12. 前記ベリファイアプロセスのサブセットを決定するステップは、ランダムネスのシャード化ソースに少なくとも一部基づいており、前記ランダムネスのシャード化ソースは、前記複数のノードが制御できないランダムデータを提供する、請求項１１に記載のコンピュータが実施する方法。
13. 前記複数の台帳シャードのうちの個々の台帳シャードにアペンドされるトランザクションのカウント、
    前記台帳シャードのうちの１つ以上についての状態情報の暗号ハッシュ、および、
    前記台帳シャードのうちの個々の台帳シャードに対応付けられたベリファイアプロセス関する情報、
    のうちの１つ以上を、分散型構成台帳に記録するステップをさらに含む、請求項８から１２のいずれか１項に記載のコンピュータが実施する方法。
14. 構成サービスが、前記複数の台帳シャードに関する指令を、前記ノードのうちの１つ以上にブロードキャストするステップをさらに含む、請求項１３に記載のコンピュータが実施する方法。
15. 請求項８から１４のいずれか１項に記載の方法をコンピュータに実行させるプログラム。

Images