JP2023520859A - ブロックチェーンのより高速なビュー変更 - Google Patents

ブロックチェーンのより高速なビュー変更 Download PDF

Info

Publication number
JP2023520859A
JP2023520859A JP2022557974A JP2022557974A JP2023520859A JP 2023520859 A JP2023520859 A JP 2023520859A JP 2022557974 A JP2022557974 A JP 2022557974A JP 2022557974 A JP2022557974 A JP 2022557974A JP 2023520859 A JP2023520859 A JP 2023520859A
Authority
JP
Japan
Prior art keywords
blockchain
message
peer
peers
view
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022557974A
Other languages
English (en)
Inventor
マネヴィッチ、ヤコブ
バーガー、アーテム
メール、ヘイガー
トック、ヨアフ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2023520859A publication Critical patent/JP2023520859A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9024Graphs; Linked lists

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Artificial Fish Reefs (AREA)
  • Agricultural Chemicals And Associated Chemicals (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

例示的な動作は、ブロックチェーンの前の一次ピアから一次ピアへのビュー変更を要求するビュー変更メッセージを受信することと、受信されたビュー変更メッセージのメタデータに基づいて、ブロックチェーンの状態に対する変更が前の一次ピアを使用して処理中であることを識別することと、受信されたビュー・データ・メッセージに基づいて、ブロックチェーンの状態に対する変更が、ブロックチェーンに対する最新の変更に対応するということを検証することと、ブロックチェーンの状態に対する処理中の変更を含んでいる新しいビュー・メッセージを、追従するピアに送信することとのうちの1つまたは複数を含む。

Description

本発明は、分散型ストレージ・システムの分野に関連しており、特に、分散型ストレージ・システムに対する更新が処理中であるときに、より高速なビュー変更が行われることを可能にするための分散型ストレージ・システムの分野に関連している。
集中データベースは、データを単一のデータベース(例えば、データベース・サーバ)に格納して一か所で維持する。この位置は、多くの場合、中央コンピュータであり、例えば、デスクトップの中央処理装置(CPU:central processing unit)、サーバCPU、またはメインフレーム・コンピュータである。集中データベースに格納された情報は、通常、複数の異なる位置からアクセス可能である。複数のユーザまたはクライアント・ワークステーションが、例えばクライアント/サーバ構成に基づいて、集中データベースを使用して同時に作業することができる。集中データベースは、単一の位置のため、特にセキュリティの目的で、管理、維持、および制御するのが容易である。集中データベース内では、すべてのデータの単一の格納場所が、特定のデータのセットのみが1つの一次記録を含むということも意味するため、データの冗長性が最小限に抑えられる。
1つの実施形態例は、ブロックチェーンの前の一次ピアから一次ピアへのビュー変更を要求するビュー変更メッセージを受信することのうちの1つまたは複数を実行するように構成されたネットワーク・インターフェイスと、受信されたビュー変更メッセージのメタデータに基づいて、ブロックチェーンの状態に対する変更が前の一次ピアを使用して処理中であることを識別し、受信されたビュー・データ・メッセージに基づいて、ブロックチェーンの状態に対する変更が、ブロックチェーンに対する最新の変更に対応するということを検証するように構成されたプロセッサとを含んでよい装置を提供し、ネットワーク・インターフェイスが、ブロックチェーンの状態に対する処理中の変更を含んでいる新しいビュー・メッセージを追従するピアに送信するように、さらに構成される。
別の実施形態例は、ブロックチェーンの現在の一次ピアが故障したピアになったということを決定することと、ブロックチェーンの状態に対する変更が、現在の一次ピアを使用して処理中であるということを識別することと、次のビュー番号およびブロックチェーンの状態に対する処理中の変更のハッシュを含んでいるビュー変更メッセージを生成することとのうちの1つまたは複数を実行するように構成されたプロセッサと、生成されたビュー変更メッセージを他のピアに送信するように構成されたネットワーク・インターフェイスとを含んでよい装置を提供する。
別の実施形態例は、ブロックチェーンの前の一次ピアから一次ピアへのビュー変更を要求するビュー変更メッセージを受信することと、受信されたビュー変更メッセージのメタデータに基づいて、ブロックチェーンの状態に対する変更が前の一次ピアを使用して処理中であることを識別することと、受信されたビュー・データ・メッセージに基づいて、ブロックチェーンの状態に対する変更が、ブロックチェーンに対する最新の変更に対応するということを検証することと、ブロックチェーンの状態に対する処理中の変更を含んでいる新しいビュー・メッセージを、追従するピアに送信することとのうちの1つまたは複数を含んでよい方法を提供する。
別の実施形態例は、一次ピアから、ブロックチェーンに追加されるよう提案されたデータを含んでいる事前準備メッセージを受信するように構成されたネットワーク・インターフェイスと、ブロックチェーンに追加されるよう提案されたデータのハッシュおよび合意ピア(consensus peer)の署名を含んでいる準備メッセージを生成すること、合意ピアのハッシュ・パズルを準備メッセージに追加すること、ならびにハッシュ・パズルを含む準備メッセージをブロックチェーンの複数の他の合意ピアに送信することのうちの1つまたは複数を実行するように構成されたプロセッサとのうちの1つまたは複数を含んでよい装置を提供する。
さらなる実施形態例は、次のビュー値およびブロックチェーンの状態に対する処理中の変更のハッシュを含んでいるビュー変更メッセージを受信するように構成されたネットワーク・インターフェイスと、既定のしきい値数のビュー変更メッセージの受信に応答して、ブロックチェーンの状態に対する処理中の変更の証明を含む他の追従するピアからの署名された準備メッセージを含んでいるビュー・データ・メッセージを生成すること、および署名された準備メッセージを含んでいる生成されたビュー・データ・メッセージを一次ピアに送信することのうちの1つまたは複数を実行するように構成されたプロセッサとのうちの1つまたは複数を含んでよい装置を提供する。
第1の態様から見ると、本発明は、ブロックチェーンの前の一次ピアから一次ピアへのビュー変更を要求するビュー変更メッセージを受信するように構成されたネットワーク・インターフェイスと、受信されたビュー変更メッセージのメタデータに基づいて、ブロックチェーンの状態に対する変更が前の一次ピアを使用して処理中であることを識別し、受信されたビュー・データ・メッセージに基づいて、ブロックチェーンの状態に対する変更が、ブロックチェーンに対する最新の変更に対応するということを検証するように構成されたプロセッサとを備えている装置を提供し、ネットワーク・インターフェイスが、ブロックチェーンの状態に対する処理中の変更を含んでいる新しいビュー・メッセージを追従するピアに送信するように、さらに構成される。
本発明は、ネットワーク・インターフェイスが、1つのビュー・データ・メッセージのみの受信に応答して新しいビュー・メッセージを送信するように構成される、装置を提供するのが好ましい。
本発明は、ブロックチェーンの状態に対する処理中の変更が、提案されたデータ・ブロックを含む、装置を提供するのが好ましい。
本発明は、プロセッサが、ビュー変更メッセージが既定のしきい値数の追従するピアから受信されたことを検証するようにさらに構成される、装置を提供するのが好ましい。
本発明は、ビュー変更メッセージごとに、メタデータが、次のビュー番号およびブロックチェーンに対するハッシュされた変更を含む、装置を提供するのが好ましい。
本発明は、ビュー・データ・メッセージが複数の準備メッセージを含み、準備メッセージが他のピアから追従するピアによって受信される、装置を提供するのが好ましい。
本発明は、プロセッサが、ブロックチェーンの状態に対する処理中の変更が、ビュー・データ・メッセージ内に格納された既定の数の署名された準備メッセージに含まれているということを検証するように構成される、装置を提供するのが好ましい。
別の態様から見ると、本発明は、ブロックチェーンの現在の一次ピアが故障したピアになったということを決定することと、ブロックチェーンの状態に対する変更が、現在の一次ピアを使用して処理中であるということを識別することと、次のビュー番号およびブロックチェーンの状態に対する処理中の変更のハッシュを含んでいるビュー変更メッセージを生成することとを実行するように構成されたプロセッサと、生成されたビュー変更メッセージを他のピアに送信するように構成されたネットワーク・インターフェイスとを備えている装置を提供する。
本発明は、プロセッサが、ブロックチェーンの状態に対する処理中の変更に合意するブロックチェーンの他の追従するピアの署名を、ビュー変更メッセージ内に格納するようにさらに構成される、装置を提供するのが好ましい。
本発明は、実用的ビザンチン・フォールト・トレランス(pBFT:practical byzantine fault tolerant)合意の準備段階中に、ブロックチェーンの状態に対する処理中の変更および署名が収集される、装置を提供するのが好ましい。
本発明は、プロセッサが、現在の一次ピアから受信された事前準備メッセージに基づいてブロックチェーンの状態に対する処理中の変更を識別するように構成される、装置を提供するのが好ましい。
別の態様から見ると、本発明は、ブロックチェーンの前の一次ピアから一次ピアへのビュー変更を要求するビュー変更メッセージを受信することと、受信されたビュー変更メッセージのメタデータに基づいて、ブロックチェーンの状態に対する変更が前の一次ピアを使用して処理中であることを識別することと、受信されたビュー・データ・メッセージに基づいて、ブロックチェーンの状態に対する変更が、ブロックチェーンに対する最新の変更に対応するということを検証することと、ブロックチェーンの状態に対する処理中の変更を含んでいる新しいビュー・メッセージを、追従するピアに送信することとを含む、一次ピアの方法を提供する。
本発明は、送信することが、1つのビュー・データ・メッセージのみの受信に応答して新しいビュー・メッセージを送信することを含む、方法を提供するのが好ましい。
本発明は、ブロックチェーンの状態に対する処理中の変更が、提案されたデータ・ブロックを含む、方法を提供するのが好ましい。
別の態様から見ると、本発明は、一次ピアから、ブロックチェーンに追加されるよう提案されたデータを含んでいる事前準備メッセージを受信するように構成されたネットワーク・インターフェイスと、ブロックチェーンに追加されるよう提案されたデータのハッシュおよび合意ピアの署名を含んでいる準備メッセージを生成すること、合意ピアのハッシュ・パズルを準備メッセージに追加すること、ならびにハッシュ・パズルを含む準備メッセージをブロックチェーンの複数の他の合意ピアに送信することを実行するように構成されたプロセッサとを備えている装置を提供する。
本発明は、プロセッサが、他の合意ピアから受信された準備メッセージに基づいて、既定のしきい値数の他の合意ピアが、ブロックチェーンに追加されるよう提案されたデータに合意するということを決定するようにさらに構成される、装置を提供するのが好ましい。
本発明は、プロセッサが、準備メッセージに追加されたハッシュ・パズルに対する解を含んでいるコミット・メッセージを生成し、そのコミット・メッセージを複数の他の合意ピアに送信するようにさらに構成される、装置を提供するのが好ましい。
本発明は、コミット・メッセージが合意ピアの署名を含まない、装置を提供するのが好ましい。
本発明は、プロセッサが、既定の秘密値のハッシュを介してハッシュ・パズルを生成するように構成される、装置を提供するのが好ましい。
本発明は、プロセッサが、他の合意ピアから準備メッセージを受信するようにさらに構成され、受信された準備メッセージが、他の各合意ピアによって追加されたハッシュ・パズルを含む、装置を提供するのが好ましい。
別の態様から見ると、本発明は、次のビュー値およびブロックチェーンの状態に対する処理中の変更のハッシュを含んでいるビュー変更メッセージを受信するように構成されたネットワーク・インターフェイスと、既定のしきい値数のビュー変更メッセージの受信に応答して、ブロックチェーンの状態に対する処理中の変更の証明を含む他の追従するピアからの署名された準備メッセージを含んでいるビュー・データ・メッセージを生成すること、および署名された準備メッセージを含んでいる生成されたビュー・データ・メッセージを一次ピアに送信することを実行するように構成されたプロセッサとを備えている装置を提供する。
本発明は、ビザンチン・フォールト・トレランス(BFT)合意の準備段階中に、署名された準備メッセージが収集される、装置を提供するのが好ましい。
本発明は、署名された準備メッセージが、ブロックチェーンの状態に対する処理中の変更のハッシュおよび新しい一次ピアのビュー番号を含んでいるメタデータを含む、装置を提供するのが好ましい。
本発明は、署名された準備メッセージが、他の追従するピアによって追加されたハッシュ・パズルをさらに含む、装置を提供するのが好ましい。
本発明は、プロセッサが、前の一次ピアからブロックチェーンの状態に対する処理中の変更を受信するようにさらに構成される、装置を提供するのが好ましい。
実施形態例に従って、ビュー変更を実行するためのブロックチェーン・ネットワークを示す図である。 実施形態例に従って、図1Aのブロックチェーン・ネットワークによって実行された合意プロセスを示す図である。 実施形態例に従って、図1Aのブロックチェーン・ネットワークによって実行されたビュー変更プロセスを示す図である。 実施形態例に従って、例示的なブロックチェーン・アーキテクチャの構成を示す図である。 実施形態例に従って、ノード間のブロックチェーン・トランザクション・フローを示す図である。 実施形態例に従って、許可型ネットワークを示す図である。 実施形態例に従って、別の許可型ネットワークを示す図である。 実施形態例に従って、許可なしネットワークを示す図である。 実施形態例に従って、ブロックチェーンの合意のための準備メッセージおよびコミット・メッセージの形式を示す図である。 実施形態例に従って、ビュー変更メッセージの形式を示す図である。 実施形態例に従って、実行されているより高速なビュー変更プロセスを示す図である。 実施形態例に従って、ビュー変更を実行する方法を示す図である。 実施形態例に従って、ビュー変更メッセージを生成する方法を示す図である。 実施形態例に従って、準備メッセージを生成する方法を示す図である。 実施形態例に従って、ビュー・データ・メッセージを生成する方法を示す図である。 実施形態例に従って、本明細書に記載された1つまたは複数の動作を実行するように構成された例示的なシステムを示す図である。 実施形態例に従って、本明細書に記載された1つまたは複数の動作を実行するように構成された別の例示的なシステムを示す図である。 実施形態例に従って、スマート・コントラクトを利用するように構成された、さらに別の例示的なシステムを示す図である。 実施形態例に従って、ブロックチェーンを利用するように構成された、さらに別の例示的なシステムを示す図である。 実施形態例に従って、分散型台帳に追加されている新しいブロックのためのプロセスを示す図である。 実施形態例に従って、新しいデータ・ブロックのデータの内容を示す図である。 実施形態例に従って、デジタル・コンテンツのためのブロックチェーンを示す図である。 実施形態例に従って、ブロックチェーン内のブロックの構造を表すことができるブロックを示す図である。 実施形態例に従って、機械学習(人工知能)データを格納する例示的なブロックチェーンを示す図である。 実施形態例に従って、例示的な量子セキュアなブロックチェーンを示す図である。 実施形態例のうちの1つまたは複数をサポートする例示的なシステムを示す図である。
本明細書の図において一般的に説明され、示されているように、本明細書のコンポーネントが、多種多様な異なる構成で配置および設計されてよいということが、容易に理解されるであろう。したがって、添付の図において表された方法、装置、非一過性コンピュータ可読媒体、およびシステムのうちの少なくとも1つの実施形態に関する以下の詳細な説明は、請求されている本出願の範囲を制限するよう意図されておらず、単に選択された実施形態を代表している。
本明細書全体を通して説明された特徴、構造、または特性は、1つまたは複数の実施形態において、任意の適切な方法で組み合わせられるか、または削除されてよい。例えば、語句「実施形態例」、「一部の実施形態」、またはその他の同様の言葉の使用は、本明細書全体を通じて、実施形態に関連して説明された特定の特徴、構造、または特性が少なくとも1つの実施形態に含まれてよいということを指している。したがって、語句「実施形態例」、「一部の実施形態において」、「その他の実施形態において」、またはその他の同様の言葉の出現は、本明細書全体を通じて、必ずしもすべてが実施形態の同じグループを指しておらず、説明された特徴、構造、または特性は、1つまたは複数の実施形態において、任意の適切な方法で組み合わせられるか、または削除されてよい。さらに、各図では、要素間の任意の接続は、示された接続が一方向または双方向の矢印である場合でも、一方向通信または双方向通信あるいはその両方を許可することができる。また、図面に示された任意のデバイスは、異なるデバイスであることができる。例えば、情報を送信しているモバイル・デバイスが示された場合、その情報を送信するために、有線デバイスも使用され得る。
加えて、「メッセージ」という用語が実施形態の説明において使用されていることがあるが、本出願は、多くの種類のネットワークおよびデータに適用されてよい。さらに、特定の種類の接続、メッセージ、および信号伝達が実施形態例において示されることがあるが、本出願は、特定の種類の接続、メッセージ、および信号伝達に限定されない。
実施形態例は、許可型ブロックチェーンのより高速なビュー変更プロセスを実施する方法、システム、コンポーネント、非一過性コンピュータ可読媒体、デバイス、またはネットワーク、あるいはその組み合わせを提供する。
1つの実施形態では、本出願は、互いに通信する複数のノードを含んでいる分散ストレージ・システムである分散型データベース(ブロックチェーンなど)を利用する。分散型データベースは、相互に信頼できない関係者間でレコードを維持することができる分散型台帳に似ている、追加専用の変更不可能なデータ構造を含む。信頼できない関係者は、本明細書ではピアまたはピア・ノードと呼ばれる。各ピアは、データベース・レコードのコピーを維持し、単一のピアは、分散されたピア間で合意に達することなく、データベース・レコードを変更することができない。例えば、ピアは、ブロックチェーン格納トランザクションの妥当性を確認し、それらの格納トランザクションをブロックにグループ化し、ブロック上にハッシュ・チェーンを構築するために、合意プロトコルを実行してよい。このプロセスは、一貫性のために、必要に応じて、格納トランザクションを順序付けることによって台帳を形成する。さまざまな実施形態では、許可型ブロックチェーンまたは許可なしブロックチェーンあるいはその両方が使用され得る。パブリック・ブロックチェーンまたは許可なしブロックチェーンには、特定の識別情報なしで、誰でも参加することができる。パブリック・ブロックチェーンは、ネイティブ暗号通貨を含み、プルーフ・オブ・ワーク(PoW:Proof of Work)などのさまざまなプロトコルに基づいて、合意を使用することができる。一方、許可型ブロックチェーン・データベースは、資金、商品、情報などを交換する企業などの、共通の目標を共有しているが、互いに完全には信用していない実体のグループ内で、安全な相互作用を提供する。
本出願は、分散型ストレージ方式に合わせてある、「スマート・コントラクト」または「チェーンコード」と呼ばれる、任意のプログラム可能な論理を操作するブロックチェーンを利用することができる。場合によっては、システム・チェーンコードと呼ばれる、管理機能およびパラメータのための特殊なチェーンコードが存在することがある。アプリケーションは、ブロックチェーン・データベースの改ざん防止の特性、および署名または署名ポリシーと呼ばれるノード間の基礎になる合意を活用する、信頼できる分散されたアプリケーションであるスマート・コントラクトをさらに利用することができる。このアプリケーションに関連付けられたブロックチェーン・トランザクションは、ブロックチェーンにコミットされる前に「署名される」ことができ、一方、署名されていないトランザクションは無視される。署名ポリシーは、チェーンコードが、トランザクションの署名者を、署名に必要なピア・ノードのセットの形態で指定できるようにする。クライアントが、トランザクションを、署名ポリシーで指定されたピアに送信するときに、トランザクションの妥当性を確認するためのトランザクションが実行される。妥当性確認の後に、トランザクションが順序付けフェーズに移行し、順序付け段階では、合意プロトコルが使用され、ブロックにグループ化された、署名されたトランザクションの順序付けられたシーケンスを生成する。
本出願は、ブロックチェーン・システムの通信実体であるノードを利用することができる。「ノード」は、異なる種類の複数のノードが同じ物理サーバ上で実行され得るという意味で、論理機能を実行してよい。ノードは、信頼できるドメイン内でグループ化され、さまざまな方法でそれらのノードを制御する論理的実体に関連付けられる。ノードは、トランザクション呼び出しを署名者(例えば、ピア)にサブミットし、トランザクション提案を順序付けサービス(例えば、順序付けノード)にブロードキャストするクライアントまたはサブミット・クライアント・ノードなどの、さまざまな種類を含んでよい。別の種類のノードは、クライアントがサブミットしたトランザクションを受信し、トランザクションをコミットし、ブロックチェーン・トランザクションの台帳の状態およびコピーを維持することができるピア・ノードである。ピアは署名者の役割を持つこともできるが、これは必須要件ではない。順序付けサービス・ノードまたは順序付けノードは、すべてのノードのための通信サービスを実行するノードであり、トランザクションをコミットするとき、およびブロックチェーンの世界状態(world state)(通常は制御情報および設定情報を含んでいる初期ブロックチェーン・トランザクションの別名)を変更するときの、システム内のピア・ノードの各々へのブロードキャストなどの、配信保証を実施する。
本出願は、ブロックチェーンのすべての状態遷移の順序付けられた改ざん防止機能付きレコードである台帳を利用することができる。状態遷移は、参加している関係者(例えば、クライアント・ノード、順序付けノード、署名者ノード、ピア・ノードなど)によってサブミットされたチェーンコード呼び出し(すなわち、トランザクション)から生じてよい。各参加している関係者(ピア・ノードなど)は、台帳のコピーを維持することができる。トランザクションは、1つまたは複数のオペランド(作成、更新、削除など)として台帳にコミットされているアセットのキーと値のペア(key-value pair)のセットをもたらしてよい。台帳は、変更不可能な順序付けられたレコードをブロックに格納するために使用されるブロックチェーン(チェーンとも呼ばれる)を含む。台帳は、ブロックチェーンの現在の状態を維持する状態データベースも含む。
本出願は、ハッシュ・リンク・ブロックとして構造化されたトランザクション・ログであるチェーンを利用することができ、各ブロックはN個のトランザクションのシーケンスを含んでおり、Nは1以上である。ブロック・ヘッダーは、ブロックのトランザクションのハッシュ、および前のブロックのヘッダーのハッシュを含んでいる。このようにして、台帳のすべてのトランザクションが順序付けられ、暗号によって一緒にリンクされてよい。したがって、ハッシュ・リンクを壊さずに台帳データを改ざんすることはできない。直前に追加されたブロックチェーンのブロックのハッシュは、それ以前に発生したチェーン上のすべてのトランザクションを表し、すべてのピア・ノードが一貫性のある信頼できる状態にあることを保証できるようにする。チェーンは、ブロックチェーンのワークロードの追加専用という性質を効率的にサポートするピア・ノードのファイル・システム(すなわち、ローカル、取り付けられたストレージ、クラウドなど)に格納されてよい。
一方、ブロックチェーン・システムは、データを変更不可能な台帳に格納すること、信用していない参加者を介して、変更不可能な台帳に対する分散された非集中的なアクセスを提供すること、どの実体も他の実体からの合意なしで変更不可能な台帳を変更することができないように、信用していない参加者間の合意のための合意要件を確立すること、スマート・コントラクトを呼び出すことなどを行う。ブロックチェーンは、(データが格納されている)ブロックを変更不可能な台帳に追加することを合意する参加者のネットワークによって形成される。ブロックは、追加される前に、変更不可能な台帳上の前のブロックにリンクされ、それによってチェーンを形成する。ブロックチェーンのこの変更不可能な破損しない性質は、偽造された情報およびハッキングからブロックチェーンを守る。また、非集中的性質は、関係者が安全に取引することができるようになる前に信用を確立する必要がないという点において、信用が存在しないという固有の性質をブロックチェーンに与える。
変更不可能な台帳の現在の状態は、チェーンのトランザクション・ログに含まれているすべてのキーの最新の値を表す。現在の状態は、チャネルに知られている最新のキーの値を表すため、世界状態と呼ばれることもある。チェーンコード呼び出しは、台帳の現在の状態のデータに対してトランザクションを実行する。それらのチェーンコードの相互作用を効率的にするために、最新のキーの値が状態データベースに格納されてよい。状態データベースは、単にチェーンのトランザクション・ログへのインデックス付きビューであってよく、したがって、いつでもチェーンから再生成され得る。状態データベースは、ピア・ノードの起動時に、トランザクションが受け取られる前に、自動的に回復されて(必要な場合は、生成されて)よい。
ブロックチェーン・ネットワークは、ブロックチェーン台帳のコピー/複製をそれぞれ保持している多くのブロックチェーン・ピアを含んでよい。ブロックチェーン・ピアのすべてにわたってブロックチェーン台帳の状態に一貫性があることを保証するために、ブロックチェーン・ネットワークによって合意プロトコルが使用される。合意に一般的に使用される1つのアルゴリズムは、実用的ビザンチン・フォールト・トレランス(pBFT)である。pBFT合意では、1つまたは複数の一次ピアが、残りのピア(本明細書では、追従するピアまたは合意ピアと呼ばれる)に対してリーダーの役割を果たす。各一次ピア(リーダー)は、追従するピアと同様に、ブロックチェーン台帳の内部状態を維持する。
データをブロックチェーンに格納することの要求がクライアントから受信された場合、一次ピアは提案を作成し、一次ピアと共にグループ化されている追従するピアに、この提案をマルチキャストする。次に、追従するピアは、ブロックチェーンの提案に関する合意が存在することを保証するために、この提案を互いに共有する。合意に達した場合、追従するピア(および一次ピア)は、ブロックチェーンの提案を各ピアの内部の台帳にコミットし、応答をクライアントに転送する。
「ビュー」は、特定のブロックチェーン・ピアが一次ピアとして機能する期間である。ビュー変更は、ある一次ピアから別の一次ピアに切り替えるプロセスである。例えば、次の一次ピアは、チェーン上のファイル内のブロックチェーン・ピアの順序などに従って、ラウンドロビン方式などで選択された追従するピアであってよい。一次ピアおよび追従するピアの両方は、チェーン上のファイル内の次の一次ピアを識別するビュー番号を格納することによって、次の一次ピアを追跡してよい。ピアは、一連のビューを経て移動することに加えて、一連のシーケンス番号も経て移動し、シーケンス番号は、ブロックチェーンに格納される次のブロックのブロック番号を表す。
ブロックチェーン・ピア(追従するピア)は、一次ピアがタイムアウト状態に入る、欠陥のある活動が発生する、などを検出した場合、ビュー変更を実行するために、ビュー変更を要求してよい。さらに多くのブロックチェーン・ピアが欠陥のある活動を検出すると、それらのブロックチェーン・ピアもビュー変更メッセージを送信する。ここで、グループ内のブロックチェーン・ピアがビュー変更メッセージを互いにブロードキャストする。十分なビュー変更メッセージが受信された場合、新しい一次ピアが新しいビューを開始する。
ビュー変更メッセージは、ブロックチェーンのどの内容/状態も提供せずに、一次ピアの変更が要求されたということの指示を含んでいる軽量のメッセージであってよい。ブロックチェーン・ピア間で既定のしきい値数のビュー変更メッセージが受信された場合、ブロックチェーン・ピアは、ブロックチェーンの現在のチェックポイントを含んでいるビュー・データ・メッセージを新しい一次ピアに送信し、それによって、故障した一次ピアが止まった場合に、新しい一次ピアが引き取ることができるようにする。
ビュー・データ・メッセージ内のブロックチェーンの現在のチェックポイントが、ブロックチェーン・ピアの合意によって合意されたということを保証するために、新しい一次ピアは、ブロックチェーンの同じチェックポイントを含む2f+1個のビュー・データ・メッセージを収集しなければならない。この場合、「f」は、合計「n」個のノードを含んでいるブロックチェーン・ネットワーク内の故障している可能性のあるノードの総数であり、n=3f+1である。ブロックチェーンのチェックポイントを含む2f+1個のビュー・データ・メッセージの受信後に、新しい一次ピアは、ビュー・データ・メッセージを含んでいる、新しい一次ピアに移動するよう追従するピアに指示する新しいビュー・メッセージを、すべてのブロックチェーン・ピアにブロードキャストしてよい。
ビュー変更メッセージの場合と全く同じように、新しい一次ピアは、新しいビュー・メッセージが送信されることができるようになる前に、2f+1個のビュー・データ・メッセージを受信するのを待たなければならない。これの理由は、ビュー・データ・メッセージが、ブロックチェーンの現在の状態およびビュー・データ・メッセージを送信したブロックチェーン・ピアの署名を含んでいるためである。新しい一次ピアが、十分なブロックチェーン・ピアがブロックチェーンの現在の状態に合意したことを確認するために、一次ピアは、ブロックチェーンの最新の状態を含んでいる少なくとも既定のしきい値数(例えば、2f+1個)のビュー・データ・メッセージが受信されるまで待たなければならない。2f+1個は、「f」個の故障したノードが存在する場合でも、正しい/欠陥のないデータ・メッセージが少なくともf+1個(すなわち、f個より少なくとも1つ多く)あるということを意味する。したがって、一次ピアは、2f+1個のビュー・データ・メッセージを使用して、大部分/定数の故障していないピアが台帳の状態に合意しているということを確認することができる。ビュー変更プロセスの欠点は、新しい一次ピアが、2f+1個のビュー変更メッセージを待たなければならず、同様に、(台帳のチェックポイントを含んでいる)2f+1個のビュー・データ・メッセージを待たなければならないということである。その結果、ビュー変更プロセス中に、かなりの量の時間が消費される。
実施形態例は、これらの欠点を克服し、ブロックチェーンに対する更新が処理中(すなわち、インフライト)であるときに、より高速なビュー変更が行われることができるようにする。特に、実施形態例は、他のブロックチェーン・ピアから収集された署名を含めるために、ブロックチェーン台帳に対する処理中の更新の間に使用される準備メッセージの内容を活用する。これらの署名は、ビュー変更メッセージに追加されることができる。ビュー変更メッセージは、インフライトであるブロックチェーンに対する提案された変更を含めるように更新されることもできる。したがって、ビュー変更プロセスを開始するためにブロックチェーン・ピアによって最初に送信されるビュー変更メッセージは、大部分のブロックチェーン・ピアが、ブロックチェーンに対する同じ更新の処理中であるということの証明を含んでよい。
この場合、新しい一次ピアが2f+1個のビュー変更メッセージを収集する場合、新しい一次ピアは、少なくともf+1個のビュー変更メッセージが故障していないノードから来ることを確認することができる。さらに、新しい一次ピアは、新しいビュー・メッセージを送信する前に、ブロックチェーンのチェックポイント/現在の状態を含んでいる(2f+1個のビュー・データ・メッセージの代わりに)1つのビュー・データ・メッセージのみを待つ必要があってよい。この場合、新しい一次ピアは、1つのビュー・データ・メッセージを待つことによって、ビュー変更メッセージ内で識別されたブロックチェーンの状態に対するインフライトの変更が、ビュー・データ・メッセージ内のブロックチェーンの現在の状態/チェックポイントに一致するということを確認することができる。したがって、ビュー変更が発生するインフライトのブロックチェーン・プロセスの間に、時間が大幅に節約されることができる。さらに、2f+1個ではなく、1つのチェックポイント・メッセージのみが処理される必要がある。
ブロックチェーンの状態に対する処理中の更新の間のビュー変更プロセスに対する改善を実施するために、実施形態例は、pBFT合意プロセス中に使用される準備メッセージに対する変更、およびビュー変更プロセス中に使用されるビュー変更メッセージに対する変更の両方を導入する。
図1Aは、実施形態例に従って、ビュー変更を実行するためのブロックチェーン・ネットワーク100を示している。図1Aを参照すると、ブロックチェーン・ネットワーク100は、ブロックチェーン110の管理を共有する複数のブロックチェーン・ピア112、114、116、および118を含んでおり、ブロックチェーン110は、図7Aの例などに示されているような、ブロックのハッシュ・リンクされたチェーンおよび状態データベースの両方を含んでよい。ブロックチェーン・ネットワーク100は、ブロックチェーン110にアクセスするために承認を必要とする許可型ブロックチェーンであってよい。ブロックチェーン110に対するアクセス権限は、ブロックチェーン・ピア112~118によって付与される。ブロックチェーン・ネットワーク100は、集中型の管理を含んでおらず、代わりに、ブロックチェーン・ピア112~118のグループによって、分散された方法で協力して管理される。ブロックチェーン110は、ブロックチェーン・ピア112~118の各々にわたって複製される。さらに、ブロックチェーン・ピア112~118にわたって格納された複製の状態の間に一貫性があることを保証するために、合意が使用される。
この例では、ブロックチェーン・ピア112~118は、実用的ビザンチン・フォールト・トレランス(pBFT)合意プロトコルに基づいて動作する。この状況では、ブロックチェーン・ピア112~118は、ブロックチェーン・ピア112~118のうちから、データがブロックチェーン110に追加されるときにリーダーとして動作する一次ピアを識別する。一次ピア112は、新しいトランザクションをブロックチェーン110に格納することの要求をクライアント120から受信してよい。一方、残りのブロックチェーン・ピアは、リーダー・ピアと共に参加する「フォロワー」と呼ばれてよい。pBFT合意は、故障したノードが存在する場合でも、正しく機能することができる。本明細書における例では、n個のノードを含んでいるブロックチェーン・ネットワーク内に、最大でf個の故障したノードが存在することがあるということが仮定され、nは3f+1以上である。したがって、ブロックチェーン・ピア間の合意が保証されるためには、少なくとも2f+1個のノードが合意に達しなければならない。すなわち、f個のノードが故障している場合、2fは、少なくとも半数のノードが故障していないということを保証する。さらに、1を追加することによって、故障したノードより多い故障していないノードが常に存在することを保証する。
図1Bは、実施形態例に従って、図1Aのブロックチェーン・ネットワークによって実行された合意プロセス100Bを示している。この例では、ブロックチェーン・ピア112~118間で達した合意に基づいて、図1Aに示されたブロックチェーン110に新しいブロックが追加される。この例では、ブロックチェーン・ピア112が、ブロックチェーン・ピア112~118の現在の一次ブロックチェーン・ピアである。しかし、一次ブロックチェーンは、時間と共に変化する。例えば、各ピア112~118は、ラウンドロビン手法などに基づいて、一次ピアとして時間を費やしてよい。また、この例では、説明の都合上、1つの一次ピアを含む4つのブロックチェーン・ピアが示されているが、ブロックチェーン・ネットワークが、フォロワー・ピア(follower peers)の異なるサブセットのためにそれぞれ働く複数の一次ピアを同時に含んでいる多くのブロックチェーン・ピアを含んでよいということが、理解されるべきである。
図1Bを参照すると、一次ピア112は、新しいトランザクションをブロックチェーン110に格納することの要求をクライアント120から受信してよい。このステップは、図面では省略されている。事前準備段階131で、一次ピア112は、トランザクションをブロックに順序付け、順序付けられたトランザクションのリストを他のブロックチェーン・ピア114、116、および118にブロードキャストしてよい。準備段階132で、ブロックチェーン・ピア114、116、および118は、トランザクションの順序付けられたリストを受信してよい。各ブロックチェーン・ピア(114、116、および118)は、トランザクションのハッシュおよび状態データベースに追加される世界の最終状態を含んでいる新たに作成されたブロックのハッシュ・コードを計算し、結果として得られたハッシュを含んでいる準備メッセージを、ネットワーク内の他のブロックチェーン・ピア(114、116、および118)にブロードキャストしてよい。このようにして、ブロックチェーン・ピアは、他のブロックチェーン・ピアから準備メッセージを受信してよい。
ブロックチェーン・ピアが、既定のしきい値数(例えば、2f+1個)の準備メッセージを受信した場合、コミット段階133で、ブロックチェーン・ピアは、コミット・メッセージを生成し、他のブロックチェーン・ピアに送信してよい。ブロックチェーン・ピアが、既定のしきい値数のコミット・メッセージを受信した場合、ブロックチェーン・ピアは、ブロックを、ブロックのチェーンおよび状態データベースに対する更新を含んでいるブロックチェーン110のローカル・コピーにコミットしてよい。
さまざまな実施形態によれば、ビューの期間(例えば、pBFT合意の期間)ごとに、一次ピアが変更されてよい。例えば、一次ピアが要求を追従するピアにブロードキャストせずに事前に定義された量の時間が経過した場合、ビュー変更プロトコルを使用して一次ピアが置き換えられてよい。必要に応じて、本物のノードの大部分が協力して、現在の主導的ノードの正当性について採決し、現在の主導的ノードを次の主導的ノードに置き換えることができる。
図1Cは、実施形態例に従って、図1Aのブロックチェーン・ネットワークによって実行されたビュー変更プロセス100Cを示している。この例では、一次ピア112が故障しているということが検出される。例えば、クライアント120が要求を一次ピア112にサブミットし、その後、一次ピア112が、既定の期間内に応答することができない、タイムアウトする、などになる。追従するブロックチェーン・ピア114、116、および118が、一次ピア112が故障したのではないかと疑った場合、ブロックチェーン・ピア114、116、および118は、ビュー変更メッセージ141を送信してよい。関連する技術では、ビュー変更メッセージは、ブロックチェーン台帳の最新のチェックポイントを含んでいる重いビュー変更メッセージであってよい。例えば、最新のチェックポイントは、ブロックチェーンの現在の状態を含んでよい。別の例として、ビュー変更メッセージは、次のビューのシーケンス番号(すなわち、次の一次ピアの識別子)のみを含んでいる軽量のビュー変更メッセージであってよい。
ブロックチェーン・ピア114、116、および118が十分な(例えば、2f+1個の)ビュー変更メッセージを受信した場合、ブロックチェーン・ピアは、ビュー・データ・メッセージ142をサブミットしてよい。ビュー・データ・メッセージ142は、ビュー変更メッセージ141が軽量のメッセージである場合にのみ使用されてよい。ビュー・データ・メッセージ142は、署名され、次の段階の証明として機能してよい。ビュー・データ・メッセージ142は、ブロックチェーンの最新のチェックポイント、および存在する場合は、次の提案(処理中の提案)を含む。しかし、ビュー・データ・メッセージ142は、新しいビューの一次ピア、この例では、ブロックチェーン・ピア114のみに送信される。新しい一次ピア114は、既定のしきい値数(例えば、2f+1)を満たすために十分なビュー変更メッセージ142を受信した後に、他のブロックチェーン・ピアからの既定のしきい値数のビュー・データ・メッセージ142を含んでいる新しいビュー・メッセージ143をブロードキャストし、それによって、新しいビューの有効性の証明として機能する。
図2Aは、実施形態例に従って、ブロックチェーン・アーキテクチャの構成200を示している。図2Aを参照すると、ブロックチェーン・アーキテクチャ200は、特定のブロックチェーン要素(例えば、ブロックチェーン・ノードのグループ202)を含んでよい。ブロックチェーン・ノード202は、1つまたは複数のノード204~210を含んでよい(単に例として、これらの4つのノードが示されている)。これらのノードは、ブロックチェーン・トランザクションの追加および妥当性確認プロセス(合意)などの、複数の活動に参加する。ブロックチェーン・ノード204~210のうちの1つまたは複数は、署名ポリシーに基づいてトランザクションに署名してよく、アーキテクチャ200内のすべてのブロックチェーン・ノードのための順序付けサービスを提供してよい。ブロックチェーン・ノードは、ブロックチェーン認証を開始し、ブロックチェーン層216に格納されたブロックチェーンの変更不可能な台帳に書き込もうとしてよく、この書き込みのコピーが、基盤になる物理的インフラストラクチャ214にも格納されてよい。ブロックチェーンの構成は、格納されたプログラム/アプリケーション・コード220(例えば、チェーンコード、スマート・コントラクトなど)にアクセスして実行するためにアプリケーション・プログラミング・インターフェイス(API:application programming interfaces)222にリンクされた1つまたは複数のアプリケーション224を含んでよく、プログラム/アプリケーション・コード220は、参加者によって要求されてカスタマイズされた構成に従って作成することができ、それら自身の状態を維持し、それら自身のアセットを制御し、外部の情報を受信することができる。ブロックチェーンの構成は、トランザクションとしてデプロイし、分散型台帳に追加することによって、すべてのブロックチェーン・ノード204~210にインストールすることができる。
ブロックチェーン・ベースまたはプラットフォーム212は、ブロックチェーン・データのさまざまな層と、サービス(例えば、暗号信用サービス、仮想実行環境など)と、新しいトランザクションを受信して格納し、データ・エントリにアクセスしようとしている監査人にアクセスを提供するために使用されてよい、基盤になる物理的コンピュータ・インフラストラクチャとを含んでよい。ブロックチェーン層216は、プログラム・コードを処理し、物理的インフラストラクチャ214に参加させるために必要な仮想実行環境へのアクセスを提供するインターフェイスを公開してよい。暗号信用サービス218は、アセット交換トランザクションなどのトランザクションを検証し、情報をプライベートに保つために使用されてよい。
図2Aのブロックチェーン・アーキテクチャの構成は、ブロックチェーン・プラットフォーム212によって公開された1つまたは複数のインターフェイスおよび提供されたサービスを介して、プログラム/アプリケーション・コード220を処理および実行してよい。コード220は、ブロックチェーンのアセットを制御してよい。例えば、コード220は、データを格納および転送することができ、スマート・コントラクトおよび条件を含む関連するチェーンコードまたは実行の対象になるその他のコード要素の形態で、ノード204~210によって実行されてよい。非限定的な例として、リマインダ、更新、または変更、更新の対象になるその他の通知、あるいはその組み合わせなどを実行するために、スマート・コントラクトが作成されてよい。スマート・コントラクト自体は、権限付与およびアクセスの要件ならびに台帳の使用に関連付けられたルールを識別するために使用され得る。例えば、スマート・コントラクト(またはスマート・コントラクトの論理を実行しているチェーンコード)は、ブロックチェーン層216に含まれている1つまたは複数の処理実態(例えば、仮想マシン)によって、ブロックチェーンに書き込まれるデータを含んでいる結果228を生成するために処理され得る、ブロックチェーン・データ226を読み取ってよい。物理的インフラストラクチャ214は、本明細書に記載されたデータまたは情報のいずれかを取り出すために利用されてよい。
高水準のアプリケーションおよびプログラミング言語を使用して、スマート・コントラクトが作成され、その後、ブロックチェーン内のブロックに書き込まれてよい。スマート・コントラクトは、ブロックチェーン(例えば、ブロックチェーン・ピアの分散ネットワーク)への登録、格納、または複製、あるいはその組み合わせが実行される実行可能コードを含んでよい。トランザクションは、スマート・コントラクトが満たされていることに関連付けられた条件に応答して実行され得る、スマート・コントラクト・コードの実行である。スマート・コントラクトの実行は、デジタル・ブロックチェーン台帳の状態に対する信頼できる変更をトリガーしてよい。スマート・コントラクトの実行によって引き起こされるブロックチェーン台帳に対する変更は、1つまたは複数の合意プロトコルを介して、ブロックチェーン・ピアの分散ネットワーク全体に自動的に複製されてよい。
スマート・コントラクトは、データをキーと値のペアの形式でブロックチェーンに書き込んでよい。さらに、スマート・コントラクト・コードは、ブロックチェーンに格納された値を読み取り、それらをアプリケーションの動作において使用することができる。スマート・コントラクト・コードは、さまざまな論理演算の出力をブロックチェーン内の1つまたは複数のブロックに書き込むことができる。このコードは、仮想マシンまたはその他のコンピューティング・プラットフォーム内の一時的データ構造を作成するために使用されてよい。ブロックチェーンに書き込まれたデータは、パブリックになること、またはプライベートとして暗号化されて維持されること、あるいはその両方が行われ得る。スマート・コントラクトによって使用/生成される一時的データは、提供された実行環境によってメモリ内に保持され、ブロックチェーンに必要なデータが識別された後に削除される。
チェーンコードは、スマート・コントラクトのコード解釈(例えば、論理)を含んでよい。例えば、チェーンコードは、スマート・コントラクト内の論理のパッケージ化されたデプロイ可能なバージョンを含んでよい。本明細書に記載されているように、チェーンコードは、コンピューティング・ネットワーク上にデプロイされるプログラム・コードであってよく、合意プロセス中に、チェーン・バリデータによって一緒に実行されて妥当性を確認される。チェーンコードは、ハッシュを受信し、以前に格納された特徴抽出機能の使用によって作成されたデータ・テンプレートに関連付けられたハッシュをブロックチェーンから取り出してよい。ハッシュ識別子のハッシュと、格納された識別子テンプレート・データから作成されたハッシュが一致する場合、チェーンコードは、権限付与キーを、要求されたサービスに送信する。チェーンコードは、暗号の詳細に関連付けられたデータをブロックチェーンに書き込んでよい。
図2Bは、実施形態例に従って、ブロックチェーンのノード間のブロックチェーン・トランザクション・フロー250の例を示している。図2Bを参照すると、トランザクション・フローは、クライアント・ノード260がトランザクション提案291を署名ピア・ノード281に送信することを含んでよい。署名ピア281は、クライアントの署名を検証し、チェーンコード関数を実行してトランザクションを開始してよい。出力は、チェーンコードの結果、チェーンコードに読み取られたキー/値のバージョンのセット(読み取りセット)、およびチェーンコードに書き込まれたキー/値のセット(書き込みセット)を含んでよい。ここで、署名ピア281は、トランザクション提案に署名するべきかどうかを決定してよい。提案応答292が、承認されている場合は署名と共に、クライアント260に返送される。クライアント260は、署名をトランザクションのペイロード293にまとめて、順序付けサービス・ノード284にブロードキャストする。その後、順序付けサービス・ノード284は、順序付けられたトランザクションをチャネル上でブロックとしてすべてのピア281~283に配信する。ブロックチェーンへのコミットの前に、各ピア281~283がトランザクションの妥当性を確認してよい。例えば、ピアは、指定されたピアの正しい割り当てが結果に署名し、トランザクションのペイロード293に対する署名を認証したことを確認するために、署名ポリシーをチェックしてよい。
再び図2Bを参照すると、クライアント・ノードが、要求を構築してピア・ノード281(署名者)に送信することによって、トランザクション291を開始する。クライアント260は、サポートされているソフトウェア開発キット(SDK:software development kit)を利用するアプリケーションを含んでよく、このアプリケーションは、使用可能なAPIを利用してトランザクション提案を生成する。提案は、データが台帳から読み取られること、または台帳に書き込まれること(すなわち、アセットの新しいキーと値のペアを書き込むこと)、あるいはその両方を実行できるように、チェーンコード関数を呼び出すことの要求である。SDKは、トランザクション提案を、適切に設計された形式(例えば、遠隔手続き呼び出し(RPC:remote procedure call)を経由するプロトコル・バッファ)にパッケージ化するためのシムとして機能し、クライアントの暗号認証情報を受け取って、トランザクション提案の一意の署名を生成してよい。
それに応じて、署名ピア・ノード281は、(a)トランザクション提案が適切に形成されていること、(b)トランザクションが過去にすでにサブミットされていないこと(リプレイアタック保護)、(c)署名が有効であること、および(d)そのチャネルに対する提案された操作を実行するための適切な権限がサブミッター(例では、クライアント260)に与えられていることを検証してよい。署名ピア・ノード281は、トランザクション提案の入力を、呼び出されるチェーンコード関数への引数として受け取ってよい。その後、チェーンコードが、現在の状態データベースに対して実行され、応答値、読み取りセット、および書き込みセットを含んでいるトランザクション結果を生成する。ただしこの時点では、台帳に対する更新は行われない。292で、値のセットが、署名ピア・ノードの281署名と共に、提案応答292としてクライアント260のSDKに返され、このSDKが、アプリケーションが使用するためのペイロードを構文解析する。
それに応じて、クライアント260のアプリケーションが、署名ピアの署名を検査/検証し、提案応答を比較して、提案応答が同じであるかどうかを判定する。チェーンコードが単に台帳に問い合わせた場合、アプリケーションは問い合わせ応答を検査し、通常は、トランザクションを順序付けノード・サービス284にサブミットしない。クライアント・アプリケーションが、台帳を更新するためにトランザクションを順序付けノード・サービス284にサブミットしようとしている場合、アプリケーションは、サブミットする前に、指定された署名ポリシーが満たされているかどうか(すなわち、トランザクションに必要なすべてのピア・ノードがトランザクションに署名したかどうか)を判定する。ここで、クライアントは、トランザクションの複数の関係者のうちの1つのみを含んでよい。この場合、各クライアントは、それ自身の署名ノードを含んでよく、各署名ノードがトランザクションに署名する必要がある。アーキテクチャは、アプリケーションが応答を検査しないことを選択するか、またはその他の方法で署名されていないトランザクションを転送する場合でも、署名ポリシーが、ピアによってまだ実施され、コミット妥当性確認フェーズで維持されるようにする。
検査に成功した後に、ステップ293で、クライアント260が、署名をトランザクション提案にまとめ、順序付けノード284へのトランザクション・メッセージ内でトランザクション提案およびトランザクション応答をブロードキャストする。トランザクションは、読み取り/書き込みセット、署名ピアの署名、およびチャネルIDを含んでよい。順序付けノード284は、その動作を実行するために、トランザクションの内容全体を検査する必要はなく、代わりに順序付けノード284は、単に、トランザクションをネットワーク内のすべてのチャネルから受信して、チャネル別に経時的に順序付けし、チャネルごとにトランザクションのブロックを作成してよい。
ブロックは、順序付けノード284からチャネル上のすべてのピア・ノード281~283に配信される。署名ポリシーが満たされていることを保証するため、および読み取りセットがトランザクションの実行によって生成されて以来、読み取りセットの変数に関して台帳の状態に対する変更がないことを保証するために、ブロック内のデータ・セクションの妥当性が確認されてよい。さらに、ステップ295で、各ピア・ノード281~283は、ブロックをチャネルのチェーンに追加し、有効なトランザクションごとに、書き込みセットが現在の状態データベースにコミットされる。トランザクション(呼び出し)が変更不可能なようにチェーンに追加されたことをクライアント・アプリケーションに通知するため、およびトランザクションの妥当性が確認されたか、または無効にされたかを通知するために、イベントが発行されてよい。
図3Aは許可型ブロックチェーン・ネットワーク300の例を示しており、許可型ブロックチェーン・ネットワーク300は、分散型の非集中的ピアツーピア・アーキテクチャを特徴とする。この例では、ブロックチェーン・ユーザ302は、許可型ブロックチェーン304に対するトランザクションを開始してよい。この例では、トランザクションは、デプロイ、呼び出し、または問い合わせであることができ、SDKを利用するクライアント側のアプリケーションを介して、APIを介して直接的に、などによって、発行されてよい。ネットワークは、監査人などのレギュレータ306へのアクセスを提供してよい。ブロックチェーン・ネットワーク・オペレータ308は、レギュレータ306を「監査人」として登録し、ブロックチェーン・ユーザ302を「クライアント」として登録するなど、メンバーの許可を管理する。監査人を、台帳への問い合わせのみに制限することができ、一方、特定の種類のチェーンコードのデプロイ、呼び出し、および問い合わせを行うための権限をクライアントに与えることができる。
ブロックチェーン開発者310は、チェーンコードおよびクライアント側のアプリケーションを書き込むことができる。ブロックチェーン開発者310は、インターフェイスを介して、チェーンコードをネットワークに直接デプロイすることができる。従来のデータ・ソース312からの認証情報をチェーンコードに含めるために、開発者310は、帯域外接続を使用してデータにアクセスすることができる。この例では、ブロックチェーン・ユーザ302は、ピア・ノード314を介して許可型ブロックチェーン304に接続する。ピア・ノード314は、いずれかのトランザクションを開始する前に、ユーザの登録およびトランザクションの証明書を、ユーザの役割および許可を管理する認証機関316から取得する。場合によっては、ブロックチェーン・ユーザは、許可型ブロックチェーン304上でトランザクションを実行するために、それらのデジタル証明書を所有しなければならない。一方、チェーンコードを利用しようとしているユーザは、従来のデータ・ソース312上のそれらのユーザの認証情報を検証することが必要になることがある。ユーザの権限付与を確認するために、チェーンコードは、従来の処理プラットフォーム318を介して、このデータへの帯域外接続を使用することができる。
図3Bは許可型ブロックチェーン・ネットワーク320の別の例を示しており、許可型ブロックチェーン・ネットワーク320は、分散型の非集中的ピアツーピア・アーキテクチャを特徴とする。この例では、ブロックチェーン・ユーザ322は、トランザクションを許可型ブロックチェーン324にサブミットしてよい。この例では、トランザクションは、デプロイ、呼び出し、または問い合わせであることができ、SDKを利用するクライアント側のアプリケーションを介して、APIを介して直接的に、などによって、発行されてよい。ネットワークは、監査人などのレギュレータ326へのアクセスを提供してよい。ブロックチェーン・ネットワーク・オペレータ328は、レギュレータ326を「監査人」として登録し、ブロックチェーン・ユーザ322を「クライアント」として登録するなど、メンバーの許可を管理する。監査人を、台帳への問い合わせのみに制限することができ、一方、特定の種類のチェーンコードのデプロイ、呼び出し、および問い合わせを行うための権限をクライアントに与えることができる。
ブロックチェーン開発者330は、チェーンコードおよびクライアント側のアプリケーションを書き込む。ブロックチェーン開発者330は、インターフェイスを介して、チェーンコードをネットワークに直接デプロイすることができる。従来のデータ・ソース332からの認証情報をチェーンコードに含めるために、開発者330は、帯域外接続を使用してデータにアクセスすることができる。この例では、ブロックチェーン・ユーザ322は、ピア・ノード334を介してネットワークに接続する。ピア・ノード334は、いずれかのトランザクションを開始する前に、ユーザの登録およびトランザクションの証明書を認証機関336から取得する。場合によっては、ブロックチェーン・ユーザは、許可型ブロックチェーン324上でトランザクションを実行するために、それらのデジタル証明書を所有しなければならない。一方、チェーンコードを利用しようとしているユーザは、従来のデータ・ソース332上のそれらのユーザの認証情報を検証することが必要になることがある。ユーザの権限付与を確認するために、チェーンコードは、従来の処理プラットフォーム338を介して、このデータへの帯域外接続を使用することができる。
一部の実施形態では、本明細書におけるブロックチェーンは、許可なしブロックチェーンであってよい。参加するために許可を必要とする許可型ブロックチェーンとは対照的に、誰でも許可なしブロックチェーンに参加することができる。例えばユーザは、許可なしブロックチェーンに参加するために、個人のアドレスを作成し、トランザクションをサブミットすることによって、したがってエントリを台帳に追加することによって、ネットワークとの情報のやりとりを開始してよい。さらに、すべての関係者が、ノードをシステム上で実行すること、およびトランザクションの検証に役立つようにマイニング・プロトコルを採用することを選択できる。
図3Cは、複数のノード354を含んでいる許可なしブロックチェーン352によって処理されているトランザクションのプロセス350を示している。送信側356は、許可なしブロックチェーン352を介して、支払いまたはその他の形態の値(例えば、証書、医療記録、契約、商品、サービス、またはデジタル・レコードにカプセル化され得る任意のその他のアセット)を受信側358に送信することを望んでいる。1つの実施形態では、送信側デバイス356および受信側デバイス358の各々は、トランザクション・パラメータのユーザ・インターフェイス制御および表示を提供する(ブロックチェーン352に関連付けられた)デジタル・ウォレットを有してよい。それに応じて、トランザクションがブロックチェーン352全体のノード354にブロードキャストされる。ブロックチェーン352のネットワーク・パラメータに応じて、ノードが、許可なしブロックチェーン352の作成者によって確立されたルール(事前に定義されるか、または動的に割り当てられてよい)に基づいてトランザクションを検証する(360)。例えば、この検証は、関わっている関係者の識別情報を検証することなどを含んでよい。トランザクションは、直ちに検証されてよく、またはトランザクションは、他のトランザクションと共にキューに配置されてよく、ノード354は、ネットワーク・ルールのセットに基づいてトランザクションが有効であるかどうかを判定する。
構造362内で、有効なトランザクションがブロック内に形成され、ロック(ハッシュ)を使用して封印される。このプロセスは、マイニング・ノードによって、ノード354間で実行されてよい。マイニング・ノードは、特に、許可なしブロックチェーン352のブロックをマイニングして作成するために、追加のソフトウェアを利用してよい。各ブロックは、ネットワークによって合意されたアルゴリズムを使用して作成されたハッシュ(例えば、256ビットの数値など)によって識別されてよい。各ブロックは、ヘッダー、チェーン内の前のブロックのヘッダーのハッシュへのポインタまたは参照、および有効なトランザクションのグループを含んでよい。前のブロックのハッシュへの参照は、ブロックの安全な独立したチェーンの作成に関連付けられる。
ブロックをブロックチェーンに追加できるようになる前に、ブロックの妥当性が確認されなければならない。許可なしブロックチェーン352の妥当性確認は、ブロックのヘッダーから得られたパズルに対する解であるプルーフ・オブ・ワーク(PoW)を含んでよい。図3Cの例には示されていないが、ブロックの妥当性確認ための別のプロセスは、プルーフ・オブ・ステークである。アルゴリズムが、数学問題を解くマイナーに報酬を与えるプルーフ・オブ・ワークとは異なり、プルーフ・オブ・ステークでは、ウェルス(「ステーク」としても定義される)に応じて、新しいブロックの作成者が確定的方法で選択される。その後、選択されたノードによって、同様の証明が実行される。
マイニング364で、ノードは、解がネットワーク全体にわたるターゲットを満たすまで、1つの変数に対して漸進的な変更を行うことによって、ブロックを解こうとする。これによってPoWを作成し、それによって、正しい答えを保証する。言い換えると、可能性のある解は、計算リソースが問題を解くことにおいて消耗されたということを証明しなければならない。一部の種類の許可なしブロックチェーンでは、マイナーに、ブロックを正しくマイニングしたことに対する報酬として価値(例えば、コインなど)が与えられることがある。
ここで、攻撃者が、1つのブロックの変更を受け入れるために、その後のすべてのブロックを変更しなければならないため、PoWプロセスは、ブロックの変更と共に、ブロックチェーンの変更を極めて困難にする。さらに、新しいブロックがマイニングされるにつれて、ブロックを変更することの困難さが増大し、その後のブロックの数が増加する。配布366で、正常に妥当性が確認されたブロックが、許可なしブロックチェーン352全体に配布され、すべてのノード354が、そのブロックを、許可なしブロックチェーン352の監査可能な台帳であるマジョリティ・チェーン(majority chain)に追加する。さらに、送信側356によってサブミットされたトランザクションにおける価値が、受信側デバイス358のデジタル・ウォレットに預け入れられるか、またはその他の方法で転送される。
図4Aは、実施形態例に従って、ブロックチェーンの合意のための準備メッセージ410およびコミット・メッセージ420の形式を示している。例えば、準備メッセージ410およびコミット・メッセージ420は、図1Bに示されたpBFT合意プロセス100Bにおける従来の準備メッセージおよびコミット・メッセージを置き換えるために使用されてよい。図4Aを参照すると、準備メッセージ410は、(例えば、事前に定義されたリストからなどの)次の一次ピアを表すビュー番号412、および追加されるブロックチェーン内の次のブロックのブロック番号を表すシーケンス番号413を含んでよい。例えば、ブロックチェーン上の直前に格納されたブロックが番号15のブロックである場合、シーケンス番号413は、番号16のブロックが追加される次のブロックであることを表す16の値を格納する。
さまざまな実施形態によれば、準備メッセージ410は、ブロックチェーンに追加される最新の提案411のハッシュを含んでもよい。関連する技術の準備メッセージは、最新の提案のハッシュを含まない。ここで、最新の提案411は、ブロックチェーンに追加される、ブロックチェーン・ピア間の合意の処理中であるトランザクションの内容/データ・ブロックを表してよい。例えば、トランザクション提案411は、ブロックチェーン台帳に追加されるブロックチェーン・トランザクションの結果として更新される(読み取られ/書き込まれる)キーと値のペアを含んでよい。最新の提案411をハッシュすることによって、更新の処理中(インフライト)であるブロックチェーン台帳の現在の状態の証拠をまだ提供しながら、準備メッセージ410のサイズは小さいままである。
準備メッセージ410は、準備メッセージ410を作成したブロックチェーン・ピアの署名414も含む。署名414は、最新の提案411、ビュー番号412、およびシーケンス番号413のハッシュに関するものである。したがって、署名414は、ブロックチェーン・ピアがブロックチェーンの追従する状態にあるということを検証する。下でさらに説明されるように、準備メッセージ410は、ハッシュ・パズル415も含む。
十分な準備メッセージ410が受信された後に、ブロックチェーン・ピアは、コミット・メッセージ420を作成して送信してよい。コミット・メッセージは、ブロックチェーン台帳に追加されるブロックチェーン提案421のダイジェスト、(例えば、事前に定義されたリストからなどの)次の一次ピアを表すビュー番号422、および追加されるブロックチェーン内の次のブロックのブロック番号を表すシーケンス番号423を含む。ここで、ビュー番号422およびシーケンス番号423は、準備メッセージ410内のビュー番号412およびシーケンス番号413に対応する。コミット・メッセージ420は、準備メッセージ410内で提供されたハッシュ・パズル415に対する解424も含む。
ブロックチェーン・ピアは、ブロックチェーン・ピアによって十分なコミット・メッセージ420が収集された場合に、ブロックチェーンを更新してよい。例えば、コミット・メッセージ420がグループ内の定数のブロックチェーン・ピアから受信された場合、(例えば、ダイジェスト421によって識別された)ブロックチェーンの更新が実行される。この例では、ブロックチェーン・ピアによって使用されるブロックチェーンに対する更新の証明は、収集されたコミット・メッセージ、およびブロックチェーンの状態に対する変更を証明するブロックチェーン・ピアの署名を含んでいる対応する準備メッセージに基づく。
実施形態例では、コミット・メッセージ420に対する署名を置き換えるために、ハッシュ・パズル415が使用されてよい。準備メッセージ410を送信する各送信側ブロックチェーン・ピアは、署名414も追加する。ブロックチェーンの合意では、システムは、ブロックチェーン・ピアがコミット・メッセージ420も送信したということを検証するための方法を必要とする。通常、この検証は、コミット・メッセージに署名することによって実行される。しかし、送信側ブロックチェーン・ピアは、署名414を準備メッセージにすでに追加している。したがって、コミット・メッセージ420に署名することは、署名を再び公開することになるため、安全ではない。代わりに送信側ブロックチェーン・ピアは、署名414を使用して準備メッセージ410に署名してよく、y=Hash(x)などのハッシュ・パズル415を追加してもよく、「x」はランダムな秘密値である。
次に、送信側ブロックチェーン・ピアは、コミット・メッセージ420内で、ハッシュ・パズル415に対する解424を公開してよい(解はxである)。ハッシュ・パズル415を検証するために、受信側ブロックチェーン・ピアは、送信側ブロックチェーン・ピアから提供されたコミット・メッセージ420内の解424をハッシュし、準備メッセージ410内のハッシュ・パズル415の同じ値に達するかどうかを判定する。解424のハッシュされたバージョンがハッシュ・パズル415と同じである場合、受信側ブロックチェーン・ピアは、同じ送信側ブロックチェーン・ピアがコミット・メッセージ420および準備メッセージ410の両方を送信したということを知る。
ブロックチェーンの状態に対するインフライトの変更を識別する最新の提案シーケンス411を含み、送信側ブロックチェーン・ピアの署名414も含むように、準備メッセージ410を変更することによって、図4Bの例で説明されるように、新しいビュー変更メッセージ430が構築されることができる。図4Bを参照すると、ビュー変更メッセージ430は、ブロックチェーンの状態に対するインフライトの変更のハッシュ提案431を含んでいる。ハッシュ提案431は、ブロックチェーンに対する変更の状態を表すために必要とされるデータの量を節約するために使用される。ここで、ハッシュ提案431は、現在の一次ピアにタイムアウト/故障が発生する前にブロックチェーン台帳に追加される処理中である内容のブロック/トランザクションのハッシュを含んでよい。ビュー変更メッセージ430は、ビュー番号(次の一次ピア)、シーケンス番号(チェーン内の次のブロック)などを含んでいるブロックチェーンの状態に関する情報を含むメタデータ432も含んでいる。
加えて、ビュー変更メッセージ430は、準備段階中に準備メッセージ410から収集されたブロックチェーン・ピアの署名433、434、および435も含んでいる。署名433、434、および435は、準備メッセージ410内の署名414に対応する。したがって、ビュー変更メッセージ430は、ハッシュ提案431を介してブロックチェーンに対するインフライトの変更の証明を提供することができ、メタデータ432を介してブロックチェーンの現在の状態を提供することができ、署名433、434、および435を介してハッシュ提案431および状態432に合意するブロックチェーン・ピアの数を提供することができる。ビュー変更メッセージ430は、現在の一次ピア442が故障していることの検出に応答して、図4Cに示されているグループ内のブロックチェーン・ピアの各々(例えば、ブロックチェーン・ピア444、446、および448のいずれか)によって構築されることができる。例えば、クライアント450からの、データをブロックチェーン台帳に追加することの要求に対するタイムアウトに応答して、故障した一次ピア442が検出されてよい。この場合、新しいデータが生成されているが、ブロックチェーンに追加される前であるプロセス内のある時点で、タイムアウトが発生してよい。
図4Cのプロセス400Cにさらに示されているように、ビュー変更メッセージ430と共にメタデータ432に基づいて新しい一次ピアが選択される。ここで、新しい一次ピアがブロックチェーン・ピア444として識別される。したがって、追従するピア446および448は、ブロックチェーンのビューに対する変更を要求するビュー変更メッセージ430を生成し、新しい一次ピア444に送信する。新しい一次ピア444が、既定のしきい値数(例えば、2f+1個)のブロックチェーン・ピアからビュー変更メッセージ430を受信した場合、新しい一次ピア444は、ビュー変更メッセージに含まれているハッシュされた提案431に基づいて、ブロックチェーン台帳に対するインフライトの変更を検証することができる。したがって、新しい一次ピア444は、ブロックチェーンの最新の状態を検証するために、1つのビュー・データ・メッセージ449のみを必要とする。
この例では、ビュー・データ・メッセージ449は、ブロックチェーンのチェックポイントを含む。ビュー・データ・メッセージ449内のチェックポイントが、定数のビュー変更メッセージ内のハッシュされた提案431に一致する場合、新しい一次ピア444は、ブロックチェーン・ピアが「遅れて」おらず、ブロックチェーンに対する現在の/最新の変更状態にあることを確認できる。したがって、新しい一次ピア444は、ビューが新しい一次ピア444に変更されたことを知らせる新しいビュー・メッセージを、残りのブロックチェーン・ピア442、446、および448に送信することができる。したがって、新しい一次ピア444は、ブロックチェーンの状態を検証するために、2f+1個のビュー・データ・メッセージを待つ代わりに、1つのビュー・データ・メッセージ449のみを待つ必要がある。
要するに、2f+1個のビュー変更メッセージ430が収集された後に、新しい一次ピア444は、最新の提案シーケンスがハッシュ提案431およびメタデータ432から来るということを知る。一部のピアが、遅れていることがあり、ビュー・データ・メッセージを新しい一次ピアに送信する最初のピアであることがある。新しい一次ピア444は、更新された追従するピアからのビュー・データ・メッセージを待たなければならず、その後、続行することができる。
本明細書における例では、十分な追従するピアが2f+1個の準備メッセージを他の追従するピアから受信した場合、新しい一次ピアは、1つのビュー・データ・メッセージのみを待つ必要がある。すなわち、2f+1個の追従するピアが、最新の提案ハッシュおよび追従するピアの署名を含む2f+1個の準備メッセージを受信した場合、変更の十分な証明を含むビュー変更メッセージが構築されることができる。しかし、準備メッセージを受信した追従するピアの数が十分でない(すなわち、2f+1未満である)場合、処理中の最新のハッシュ提案の十分な証明が存在しない。したがって、新しい一次ピアは、図1Cに示されたプロセス100Cにおけるように、2f+1個のビュー・データ・メッセージを待たなければならない。
図5Aは、実施形態例に従って、ビュー変更メッセージに基づいてビュー変更を実行する方法500を示している。非限定的な例として、方法500は、ブロックチェーン・ピア上などで実行されているプログラムなどによって実行されてよい。図5Aを参照すると、502で、この方法は、ブロックチェーンの前の一次ピアから一次ピアへのビュー変更を要求するビュー変更メッセージを受信することを含んでよい。例えば、ビュー変更メッセージは、ブロックチェーン・ネットワーク内の追従するピアから受信されてよい。
504で、この方法は、受信されたビュー変更メッセージのメタデータに基づいて、ブロックチェーンの状態に対する変更が前の一次ピアを使用して処理中であることを識別することを含んでよい。例えば、ブロックチェーンの状態に対する変更は、ブロックチェーンに追加されるデータ・ブロック内に格納されているブロックチェーン・トランザクションを含んでよい。トランザクションは、ブロックチェーンに対して値を更新すること、削除すること、追加することなどを実行するキーと値のペアを含んでよく、キーと値のペアは、ブロックチェーン台帳の状態データベースに格納される。
506で、この方法は、受信されたビュー・データ・メッセージに基づいて、ブロックチェーンの状態に対する変更が、ブロックチェーンに対する最新の変更に対応するということを検証することを含んでよい。例えば、ブロックチェーンの状態に対する変更は、追従するピアから受信された、ブロックチェーンに対する処理中の変更を含むブロックチェーンの状態を含んでいるビュー・データ・メッセージから識別されてよい。508で、この方法は、ブロックチェーンの状態に対する処理中の変更を含んでいる新しいビュー・メッセージを他の追従するピアに送信することを含んでよい。例えば、送信することは、1つのビュー・データ・メッセージのみを受信することに応答して新しいビュー・メッセージを送信することを含んでよい。
一部の実施形態では、ブロックチェーンの状態に対する処理中の変更は、コミットされる提案されたデータ・ブロックを含んでよい。一部の実施形態では、識別することは、ビュー変更メッセージが既定のしきい値数の追従するピアから受信されたことを検証することをさらに含んでよい。一部の実施形態では、ビュー変更メッセージごとに、メタデータが、次のビュー番号およびブロックチェーンに対するハッシュされた変更を含んでよい。一部の実施形態では、ビュー・データ・メッセージは、主導的ピアによってブロードキャストされ、追従するピアによって受信される、複数の準備メッセージを含んでよい。一部の実施形態では、検証することは、ブロックチェーンの状態に対する処理中の変更が、ビュー・データ・メッセージ内に格納された既定の数の準備メッセージに含まれているということを検証することを含んでよい。
一部の実施形態では、処理中の変更は、ビュー変更およびビュー・データ・メッセージを受信しているピアに関してまだコミットされていない、ブロックチェーンの状態に対する変更であってよい。しかし、場合によっては、この変更は、すでにコミットされていてよい。ピアは、処理中の変更を識別するメッセージを収集することによって、処理中の変更をすでにコミットしたブロックチェーン・ピアが使用不可能である場合に、異なる変更がブロックチェーンにコミットされていないということを確認することができる。
図5Bは、実施形態例に従って、ビュー変更メッセージを生成する方法510を示している。例えば、方法510は、ブロックチェーン・ピア上などで実行されているプログラムによって実行されてよい。図5Bを参照すると、512で、この方法は、ブロックチェーンの現在の一次ピアが故障したピアになったことを決定することを含んでよい。例えば、ブロックチェーン・ピアは、ブロックチェーン・ネットワークの複数のブロックチェーン・ピア間で実行されている合意プロセス中に、現在の一次ピアがタイムアウトしたことなどを検出してよい。
514で、この方法は、ブロックチェーンの状態に対する変更が現在の一次ピアを使用して処理中であることを識別することを含んでよい。例えば、ピアは、ブロックチェーンの状態に対する処理中の変更を含んでいる事前準備メッセージを、現在の一次ピアから受信していてよい。516で、この方法は、次のビュー番号およびブロックチェーンの状態に対する処理中の変更のハッシュを含んでいるビュー変更メッセージを生成することを含んでよい。さらに、518で、この方法は、ビュー変更メッセージを新しい一次ピアに送信することを含んでよい。
一部の実施形態では、この方法は、ブロックチェーンの状態に対する処理中の変更に合意するブロックチェーンの他の追従するピアの署名を、ビュー変更メッセージ内に格納することをさらに含んでよい。一部の実施形態では、ビザンチン・フォールト・トレランス(BFT)合意の準備段階中に、ブロックチェーンの状態に対する処理中の変更および署名が収集される。例えば、ブロックチェーンの状態に対する処理中の変更は、ブロックチェーンに追加される新しいブロックを含む。
図5Cは、実施形態例に従って、準備メッセージを生成する方法520を示している。図5Cを参照すると、522で、この方法は、ブロックチェーンに追加されるよう提案されたデータを含んでいる事前準備メッセージを一次ピアから受信することを含んでよい。524で、この方法は、ブロックチェーンに追加されるよう提案されたデータのハッシュおよび合意ピアの署名を含んでいる準備メッセージを生成することを含んでよい。526で、この方法は、合意ピアのハッシュ・パズルを準備メッセージに追加することを含んでよい。528で、この方法は、ハッシュ・パズルを含む準備メッセージをブロックチェーンの複数の他の合意ピアに送信することを含んでよい。
一部の実施形態では、この方法は、他の合意ピアから受信された準備メッセージに基づいて、既定のしきい値数の他の合意ピアが、ブロックチェーンに追加されるよう提案されたデータに合意するということを決定することをさらに含んでよい。一部の実施形態では、この方法は、準備メッセージに追加されたハッシュ・パズルに対する解を含んでいるコミット・メッセージを生成し、そのコミット・メッセージを複数の他の合意ピアに送信することをさらに含んでよい。一部の実施形態では、コミット・メッセージは、合意ピアの署名を含まない。一部の実施形態では、この方法は、事前に定義された秘密値のハッシュを介してハッシュ・パズルを生成することを含んでよい。一部の実施形態では、この方法は、他の合意ピアから準備メッセージを受信することをさらに含んでよく、受信された準備メッセージが、他の各合意ピアによって追加されたハッシュ・パズルを含む。
図5Dは、実施形態例に従って、ビュー・データ・メッセージを生成する方法530を示している。図5Dを参照すると、532で、この方法は、次のビュー値およびブロックチェーンの状態に対する処理中の変更のハッシュを含んでいるビュー変更メッセージを受信することを含んでよい。既定のしきい値数のビュー変更メッセージを受信することに応答して、534で、この方法は、ブロックチェーンの状態に対する処理中の変更の証明を含む他の追従するピアからの署名された準備メッセージを含んでいるビュー・データ・メッセージを生成することを含んでよい。536で、この方法は、署名された準備メッセージを含んでいる生成されたビュー・データ・メッセージを一次ピアに送信することを含んでよい。
一部の実施形態では、この方法は、ビザンチン・フォールト・トレランス(BFT)合意の準備段階中に、署名された準備メッセージを収集することをさらに含んでよい。一部の実施形態では、署名された準備メッセージは、ブロックチェーンの状態に対する処理中の変更のハッシュおよび新しい一次ピアのビュー番号を含んでいるメタデータを含んでよい。一部の実施形態では、署名された準備メッセージは、他の追従するピアによって追加されたハッシュ・パズルをさらに含む。一部の実施形態では、この方法は、一次ピアが故障する前に、ブロックチェーンの状態に対する処理中の変更を一次ピアから受信することをさらに含む。
図6Aは、実施形態例に従ってさまざまな動作を実行するように構成された物理的インフラストラクチャ610を含んでいる例示的なシステム600を示している。図6Aを参照すると、物理的インフラストラクチャ610は、モジュール612およびモジュール614を含んでいる。モジュール614は、実施形態例のいずれかに含まれる(モジュール612内の)動作ステップ608のいずれかを実行してよい、ブロックチェーン620およびスマート・コントラクト630(ブロックチェーン620に存在してよい)を含んでいる。ステップ/動作608は、説明されたか、または図に示された実施形態のうちの1つまたは複数を含んでよく、1つまたは複数のスマート・コントラクト630またはブロックチェーン620あるいはその両方から書き込まれるか、または読み取られる、出力されたか、または書き込まれた情報を表してよい。物理的インフラストラクチャ610、モジュール612、およびモジュール614は、1つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはその組み合わせを含んでよい。さらに、モジュール612およびモジュール614は同じモジュールであってよい。
図6Bは、実施形態例に従ってさまざまな動作を実行するように構成された別の例示的なシステム640を示している。図6B参照すると、システム640はモジュール612および614を含んでいる。モジュール614は、実施形態例のいずれかに含まれる(モジュール612内の)動作ステップ608のいずれかを実行してよい、ブロックチェーン620およびスマート・コントラクト630(ブロックチェーン620に存在してよい)を含んでいる。ステップ/動作608は、説明されたか、または図に示された実施形態のうちの1つまたは複数を含んでよく、1つまたは複数のスマート・コントラクト630またはブロックチェーン620あるいはその両方から書き込まれるか、または読み取られる、出力されたか、または書き込まれた情報を表してよい。モジュール612およびモジュール614は、1つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはその組み合わせを含んでよい。さらに、モジュール612およびモジュール614は同じモジュールであってよい。
図6Cは、実施形態例に従って、契約当事者間でのスマート・コントラクトの構成、およびブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された仲介サーバを利用するように構成された例示的なシステムを示している。図6Cを参照すると、構成650は、通信セッション、アセット転送セッション、あるいはプロセスまたは手順を表してよく、これらは、1つまたは複数のユーザ・デバイス652または656あるいはその両方を明示的に識別するスマート・コントラクト630によって動作させられる。スマート・コントラクトの実行の、実行、動作、および結果は、サーバ654によって管理されてよい。スマート・コントラクト630の内容は、スマート・コントラクト・トランザクションの関係者である実体652および656のうちの1つまたは複数によるデジタル署名を要求してよい。スマート・コントラクトの実行結果は、ブロックチェーン・トランザクションとしてブロックチェーン620に書き込まれてよい。スマート・コントラクト630は、1つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはその組み合わせに存在してよい、ブロックチェーン620に存在する。
図6Dは、実施形態例に従って、ブロックチェーンを含んでいるシステム660を示している。図6Dの例を参照すると、アプリケーション・プログラミング・インターフェイス(API)ゲートウェイ662が、ブロックチェーンの論理(例えば、スマート・コントラクト630またはその他のチェーンコード)およびデータ(例えば、分散型台帳など)にアクセスするための共通インターフェイスを提供する。この例では、APIゲートウェイ662は、1つまたは複数の実体652および656をブロックチェーン・ピア(すなわち、サーバ654)に接続することによってブロックチェーンに対してトランザクション(呼び出し、問い合わせなど)を実行するための共通インターフェイスである。ここで、サーバ654は、世界状態および分散型台帳のコピーを保持するブロックチェーン・ネットワークのピア・コンポーネントであり、これらのコピーは、クライアント652および656が世界状態に関するデータを問い合わせること、およびトランザクションをブロックチェーン・ネットワークにサブミットすることを可能にし、スマート・コントラクト630および署名ポリシーに応じて、署名ピアがスマート・コントラクト630を実行する。
前述の実施形態は、ハードウェアにおいて、プロセッサによって実行されるコンピュータ・プログラムにおいて、ファームウェアにおいて、またはこれらの組み合わせにおいて実装されてよい。コンピュータ・プログラムは、ストレージ媒体などのコンピュータ可読媒体に具現化されてよい。例えば、コンピュータ・プログラムは、ランダム・アクセス・メモリ(RAM:random access memory)、フラッシュ・メモリ、読み取り専用メモリ(ROM:read-only memory)、消去可能プログラマブル読み取り専用メモリ(EPROM:erasable programmable read-only memory)、電子的消去可能プログラマブル読み取り専用メモリ(EEPROM:electrically erasable programmable read-only memory)、レジスタ、ハード・ディスク、取り外し可能なディスク、コンパクト・ディスク読み取り専用メモリ(CD-ROM:compact disk read-only memory)、または従来技術において知られた任意のその他の形態のストレージ媒体に存在してよい。
例示的なストレージ媒体は、プロセッサがストレージ媒体から情報を読み取り、ストレージ媒体に情報を書き込むことができるように、プロセッサに結合されてよい。代替方法では、ストレージ媒体はプロセッサと一体であってよい。プロセッサおよびストレージ媒体は、特定用途向け集積回路(ASIC:application specific integrated circuit)に存在してよい。代替方法では、プロセッサおよびストレージ媒体は、個別のコンポーネントとして存在してよい。
図7Aは、実施形態例に従って、分散型台帳720に追加されている新しいブロックのプロセス700を示しており、図7Bは、実施形態例に従って、ブロックチェーンの新しいデータ・ブロック構造730の内容を示している。図7Aを参照すると、クライアント(図示されていない)は、トランザクションをブロックチェーン・ノード711、712、または713、あるいはその組み合わせにサブミットしてよい。クライアントは、ブロックチェーン720に対する活動を規定するための、いずれかのソースから受信された命令であってよい。一例として、クライアントは、ブロックチェーンのトランザクションを提案するデバイス、人、または実体などの要求者の代わりに動作するアプリケーションであってよい。複数のブロックチェーン・ピア(例えば、ブロックチェーン・ノード711、712、および713)が、ブロックチェーン・ネットワークの状態および分散型台帳720のコピーを維持してよい。クライアントによって提案されたトランザクションをシミュレートして署名する署名ピア、および署名を検証し、トランザクションの妥当性を確認し、トランザクションを分散型台帳720にコミットするコミット・ピアを含む、さまざまな種類のブロックチェーン・ノード/ピアが、ブロックチェーン・ネットワーク内に存在してよい。この例では、ブロックチェーン・ノード711、712、および713は、署名者ノード、コミッター・ノード(committer node)、あるいはその両方の役割を実行してよい。
分散型台帳720は、ブロック内の変更不可能な順序付けられたレコードを格納するブロックチェーン、およびブロックチェーン722の現在の状態を維持する状態データベース724(現在の世界状態)を含む。1つのチャネルにつき1つの分散型台帳720が存在してよく、各ピアが、そのピアがメンバーであるチャネルごとに、分散型台帳720のそれ自身のコピーを維持する。ブロックチェーン722は、ハッシュ・リンク・ブロックとして構造化されたトランザクション・ログであり、各ブロックがN個のトランザクションのシーケンスを含む。ブロックは、図7Bに示されているコンポーネントなどの、さまざまなコンポーネントを含んでよい。ブロックのリンク(図7Aの矢印によって示されている)は、前のブロックのヘッダーのハッシュを、現在のブロックのブロック・ヘッダー内に追加することによって生成されてよい。このようにして、ブロックチェーン722上のすべてのトランザクションが、順序付けられ、暗号によって一緒にリンクされ、ハッシュ・リンクを壊さずにブロックチェーン・データを改ざんすることを防ぐ。さらに、これらのリンクのため、ブロックチェーン722内の最新のブロックが、その前に来たすべてのトランザクションを表す。ブロックチェーン722は、追加専用のブロックチェーンのワークロードをサポートするピアのファイル・システム(ローカルまたは取り付けられたストレージ)に格納されてよい。
ブロックチェーン722および分散型台帳722の現在の状態が、状態データベース724に格納されてよい。ここで、現在の状態データは、ブロックチェーン722のチェーン・トランザクション・ログにこれまで含まれたすべてのキーの最新の値を表す。チェーンコード呼び出しは、状態データベース724内の現在の状態に対してトランザクションを実行する。それらのチェーンコードの相互作用を極めて効率的にするために、すべてのキーの最新の値が状態データベース724に格納される。状態データベース724は、ブロックチェーン722のトランザクション・ログへのインデックス付きビューを含んでよく、したがって、いつでもチェーンから再生成され得る。状態データベース724は、ピアの起動時に、トランザクションが受け取られる前に、自動的に回復されてよい(または必要な場合に生成されてよい)。
署名ノードは、トランザクションをクライアントから受信し、シミュレーション結果に基づいてトランザクションに署名する。署名ノードは、トランザクション提案をシミュレートするスマート・コントラクトを保持する。署名ノードがトランザクションに署名するときに、署名ノードは、シミュレートされたトランザクションの署名を示す署名ノードからクライアント・アプリケーションへの署名された応答である、トランザクションの署名を生成する。トランザクションに署名する方法は、チェーンコード内で指定されることがある署名ポリシーによって決まる。署名ポリシーの例は、「署名ピアの大部分がトランザクションに署名しなければならない」である。異なるチャネルは、異なる署名ポリシーを有してよい。署名されたトランザクションは、クライアント・アプリケーションによって順序付けサービス710に転送される。
順序付けサービス710は、署名されたトランザクションを受け取り、それらをブロック内に順序付けし、ブロックをコミット・ピアに配信する。例えば、順序付けサービス710は、トランザクションのしきい値に達したか、タイマーがタイムアウトするか、または別の条件の場合に、新しいブロックを開始してよい。図7Aの例では、ブロックチェーン・ノード712は、ブロックチェーン720に格納するための新しいデータの新しいデータ・ブロック730を受信したコミット・ピアである。ブロックチェーン内の第1のブロックは、ブロックチェーン、ブロックチェーンのメンバー、格納されたデータなどに関する情報を含んでいるジェネシス・ブロックと呼ばれてよい。
順序付けサービス710は、順序付けノードのクラスタで構成されてよい。順序付けサービス710は、トランザクション、スマート・コントラクトを処理することも、共有台帳を維持することもない。むしろ、順序付けサービス710は、署名されたトランザクションを受け取ってよく、それらのトランザクションが分散型台帳720にコミットされる順序を指定する。ブロックチェーン・ネットワークのアーキテクチャは、「順序付け」の特定の実装(例えば、Solo、Kafka、BFTなど)が着脱可能なコンポーネントになるように設計されてよい。
トランザクションは、一貫性のある順序で分散型台帳720に書き込まれる。トランザクションの順序は、トランザクションがネットワークにコミットされるとき状態データベース724に対する更新が有効であることを保証するように確立される。暗号パズルを解くことまたはマイニングによって順序付けが発生する暗号通貨ブロックチェーン・システム(例えば、ビットコインなど)とは異なり、この例では、分散型台帳720の関係者が、そのネットワークに最も適した順序付けメカニズムを選択してよい。
順序付けサービス710は、新しいデータ・ブロック730を初期化し、新しいデータ・ブロック730がコミット・ピア(例えば、ブロックチェーン・ノード711、712、および713)にブロードキャストされてよい。それに応じて、各コミット・ピアは、読み取りセットおよび書き込みセットが状態データベース724内の現在の世界状態にまだ一致することをチェックして確認することによって、新しいデータ・ブロック730内のトランザクションの妥当性を確認する。特に、コミット・ピアは、署名者がトランザクションをシミュレートしたときに存在していた読み取られたデータが、状態データベース724内の現在の世界状態と同一であるかどうかを判定することができる。コミット・ピアがトランザクションの妥当性を確認した場合、トランザクションが分散型台帳720のブロックチェーン722に書き込まれ、状態データベース724が、読み取り/書き込みセットからの書き込みデータに更新される。トランザクションが失敗した場合、すなわち、コミット・ピアが、読み取り/書き込みセットが状態データベース724内の現在の世界状態に一致しないということを検出した場合、ブロック内に順序付けられたトランザクションは、そのブロックにまだ含まれるが、無効としてマーク付けされ、状態データベース724が更新されない。
図7Bを参照すると、分散型台帳720のブロックチェーン722に格納された新しいデータ・ブロック730(データ・ブロックとも呼ばれる)が、ブロック・ヘッダー740、ブロック・データ750(ブロック・データ・セクション)、およびブロック・メタデータ760などの、複数のデータ・セグメントを含んでよい。図7Bに示された新しいデータ・ブロック730およびその内容などの、さまざまな示されたブロックおよびそれらの内容が、例にすぎず、実施形態例の範囲を制限するよう意図されていないということが、理解されるべきである。従来のブロックでは、データ・セクションが、データ・ブロック750内のN個(例えば、1、10、100、500、1000、2000、3000など)のトランザクションのトランザクション情報を格納してよい。
新しいデータ・ブロック730は、(例えば、図7Aのブロックチェーン722上の)前のブロックへのリンクをブロック・ヘッダー740内に含んでもよい。特に、ブロック・ヘッダー740は、前のブロックのヘッダーのハッシュを含んでよい。ブロック・ヘッダー740は、新しいデータ・ブロック730の一意のブロック番号、ブロック・データ750のハッシュなどを含んでもよい。新しいデータ・ブロック730のブロック番号は、一意であり、0から開始する漸進的/連続的順序などのさまざまな順序で割り当てられてよい。
ブロック・メタデータ760は、メタデータの複数のフィールドを(例えば、バイト配列などとして)格納してよい。メタデータ・フィールドは、ブロック作成時の署名、最後の構成ブロックへの参照、ブロック内の有効なトランザクションと無効なトランザクションを識別するトランザクション・フィルタ、ブロックを順序付けた順序付けサービスの永続的な最後のオフセットなどを含んでよい。順序付けサービス710によって署名、最後の構成ブロック、および順序付けノードのメタデータが追加されてよい。一方、ブロックのコミッター(ブロックチェーン・ノード712など)は、署名ポリシー、読み取り/書き込みセットの検証などに基づいて、有効/無効情報を追加してよい。トランザクション・フィルタは、ブロック・データ750に含まれているトランザクションの数に等しいサイズのバイト配列、およびトランザクションが有効/無効だったかどうかを識別する妥当性確認コードを含んでよい。
図7Cは、本明細書に記載された実施形態に従って、デジタル・コンテンツのためのブロックチェーン770の実施形態を示している。デジタル・コンテンツは、1つまたは複数のファイルおよび関連する情報を含んでよい。これらのファイルは、媒体、画像、ビデオ、音声、テキスト、リンク、グラフィックス、アニメーション、Webページ、文書、またはデジタル・コンテンツのその他の形態を含んでよい。ブロックチェーンの変更不可能な追加専用の特徴は、デジタル・コンテンツの完全性、有効性、および信頼性を保護するための予防手段として役立ち、認容性ルールが適用される法的手続きにおいて、あるいは証拠が考慮されるか、またはデジタル情報の提示および使用がその他の方法で対象になる、その他の設定において、ブロックチェーンの使用を適切にする。この場合、デジタル・コンテンツはデジタル証拠と呼ばれることがある。
ブロックチェーンは、さまざまな方法で形成されてよい。1つの実施形態では、デジタル・コンテンツは、ブロックチェーン自体に含まれ、ブロックチェーン自体からアクセスされてよい。例えば、ブロックチェーンの各ブロックは、参照情報(例えば、ヘッダー、値など)のハッシュ値を、関連するデジタル・コンテンツと共に格納してよい。その後、ハッシュ値および関連するデジタル・コンテンツは、一緒に暗号化されてよい。したがって、各ブロックのデジタル・コンテンツは、ブロックチェーン内の各ブロックを復号することによってアクセスされてよく、各ブロックのハッシュ値は、前のブロックを参照するための基礎として使用されてよい。これは、次のように示されてよい。
ブロック1 ブロック2 ・・・・・・ブロックN
ハッシュ値1 ハッシュ値2 ハッシュ値N
デジタル・コンテンツ1 デジタル・コンテンツ2 デジタル・コンテンツN
1つの実施形態では、デジタル・コンテンツがブロックチェーンに含まれなくてよい。例えば、ブロックチェーンは、デジタル・コンテンツを含んでいない各ブロックの内容の暗号化されたハッシュを格納してよい。デジタル・コンテンツは、元のファイルのハッシュ値に関連して、別のストレージ領域またはメモリ・アドレスに格納されてよい。他のストレージ領域は、ブロックチェーンを格納するために使用されるストレージ・デバイスと同じストレージ・デバイスであってよく、または異なるストレージ領域もしくは分離したリレーショナル・データベースであってもよい。各ブロックのデジタル・コンテンツは、対象のブロックのハッシュ値を取得するか、または問い合わせ、次に、実際のデジタル・コンテンツに対応して格納されているハッシュ値をストレージ領域内で検索することによって、参照またはアクセスされてよい。この動作は、例えば、データベース・ゲートキーパーによって実行されてよい。これは、次のように示されてよい。
ブロックチェーン ストレージ領域
ブロック1のハッシュ値 ブロック1のハッシュ値・・・内容
・ ・
・ ・
・ ・
ブロックNのハッシュ値 ブロックNのハッシュ値・・・内容
図7Cの実施形態例では、ブロックチェーン770は、順序付けられたシーケンスで暗号によってリンクされた複数のブロック778、778、...778を含んでおり、N≧1である。ブロック778、778、...778をリンクするための使用される暗号化は、複数の鍵付きハッシュ関数または鍵なしハッシュ関数のいずれかであってよい。1つの実施形態では、ブロック778、778、...778は、ブロック内の情報に基づいて入力からnビットの英数字出力を生成するハッシュ関数の対象になる(nは256または別の数である)。そのようなハッシュ関数の例としては、SHA型(SHAは、セキュア・ハッシュ・アルゴリズム(Secured Hash Algorithm)を表す)アルゴリズム、マークル・ダンガード・アルゴリズム、HAIFAアルゴリズム、マークル・ツリー・アルゴリズム、ノンスに基づくアルゴリズム、および非衝突耐性PRFアルゴリズムが挙げられるが、これらに限定されない。別の実施形態では、ブロック778、778、...778は、ハッシュ関数とは異なる関数によって、暗号によってリンクされてよい。例示の目的で、以下では、ハッシュ関数(例えば、SHA-2)を参照して説明が行われる。
ブロックチェーン内のブロック778、778、...778の各々は、ヘッダー、ファイルのバージョン、および値を含む。ヘッダーおよび値は、ブロックチェーン内のハッシュ処理の結果として、ブロックごとに異なる。1つの実施形態では、値がヘッダーに含まれてよい。以下でさらに詳細に説明されるように、ファイルのバージョンは、元のファイルであるか、または元のファイルの異なるバージョンであってよい。
ブロックチェーン内の最初のブロック778は、ジェネシス・ブロックと呼ばれ、ヘッダー772、元のファイル774、および初期値776を含んでいる。ジェネシス・ブロックに使用される(実際には、その後のすべてのブロックにおいて使用される)ハッシュ処理方式は、変化してよい。例えば、最初のブロック778内のすべての情報が一緒に同時にハッシュされてよく、または最初のブロック778内の情報の各々または一部が別々にハッシュされ、その後、別々にハッシュされた部分のハッシュが実行されてよい。
ヘッダー772は、1つまたは複数の初期パラメータを含んでよく、初期パラメータは、例えば、バージョン番号、タイムスタンプ、ノンス、ルート情報、難易度、合意プロトコル、期間、媒体形式、ソース、記述的キーワード、あるいは元のファイル774もしくはブロックチェーンまたはその両方に関連付けられたその他の情報、あるいはその組み合わせを含んでよい。ヘッダー772は、自動的に(例えば、ブロックチェーン・ネットワーク管理ソフトウェアによって)生成されるか、またはブロックチェーンの参加者によって手動で生成されてよい。ブロックチェーン内の他のブロック778~778内のヘッダーとは異なり、ジェネシス・ブロック内のヘッダー772は、単に前のブロックが存在しないため、前のブロックを参照しない。
ジェネシス・ブロック内の元のファイル774は、例えば、ブロックチェーンに含まれる前の処理を伴うか、または伴わずに、デバイスによって捕捉されたデータであってよい。元のファイル774は、システムのインターフェイスを介して、デバイス、媒体ソース、またはノードから受信される。元のファイル774はメタデータに関連付けられ、メタデータは、例えば、ユーザ、デバイス、またはシステム・プロセッサあるいはその組み合わせによって、手動または自動のいずれかで、生成されてよい。メタデータは、元のファイル774に関連して、最初のブロック778に含まれてよい。
ジェネシス・ブロック内の値776は、元のファイル774の1つまたは複数の一意の属性に基づいて生成された初期値である。1つの実施形態では、1つまたは複数の一意の属性は、元のファイル774のハッシュ値、元のファイル774のメタデータ、およびファイルに関連付けられたその他の情報を含んでよい。1つの実装では、初期値776は、以下の一意の属性に基づいてよい。
1)SHA-2によって元のファイルに対して計算されたハッシュ値
2)発信デバイスID
3)元のファイルの開始タイムスタンプ
4)元のファイルの初期ストレージ位置
5)元のファイルおよび関連するメタデータを現在制御するためのソフトウェアのブロックチェーン・ネットワーク・メンバーID
ブロックチェーン内の他のブロック778~778も、ヘッダー、ファイル、および値を含む。しかし、最初のブロック772とは異なり、他のブロック内のヘッダー772~772の各々は、直前のブロックのハッシュ値を含む。直前のブロックのハッシュ値は、単に前のブロックのヘッダーのハッシュであってよく、または前のブロック全体のハッシュ値であってよい。先行するブロックのハッシュ値を残りのブロックの各々に含めることによって、矢印780によって示されているように、N番目のブロックからジェネシス・ブロック(および関連する元のファイル)まで戻りブロックごとのトレースを実行することができ、監査可能かつ変更不可能な証拠保全を確立する。
他のブロック内のヘッダー772~772の各々は、一般に、他の情報(例えば、バージョン番号、タイムスタンプ、ノンス、ルート情報、難易度、合意プロトコル、あるいは対応するファイルもしくはブロックチェーンまたはその両方に関連付けられたその他のパラメータまたは情報、あるいはその組み合わせ)を含んでもよい。
他のブロック内のファイル774~774は、例えば実行される処理の種類に応じて、ジェネシス・ブロック内の元のファイルと同じであってよく、または元のファイルの変更されたバージョンであってよい。実行される処理の種類は、ブロックごとに変化してよい。処理は、例えば、情報を編集するか、またはその他の方法で情報の内容を変更するか、情報をファイルから取り除くか、または情報をファイルに追加するなどの、先行するブロック内のファイルの任意の変更を含んでよい。
追加的または代替的に、処理は、先行するブロックからファイルを単にコピーすること、ファイルのストレージ位置を変更すること、1つまたは複数の先行するブロックからのファイルを分析すること、ファイルをあるストレージまたはメモリ位置から別のストレージまたはメモリ位置に移動すること、あるいはブロックチェーンのファイルもしくは関連するメタデータまたはその両方に対して動作を実行することを含んでよい。ファイルを分析することを含んでいる処理は、例えば、さまざまな分析、統計値、またはファイルに関連付けられたその他の情報を追加すること、含めること、またはその他の方法で関連付けることを含んでよい。
他のブロック内の他のブロック776~776の各々に含まれる値は、実行された処理の結果として、一意の値であり、すべて異なっている。例えば、いずれか1つのブロック内の値は、前のブロック内の値の更新されたバージョンに対応する。この更新は、値が割り当てられたブロックのハッシュに反映される。したがって、ブロックの値は、ブロック内で何の処理が実行されたかの指示を提供し、ブロックチェーンを元のファイルまで戻りトレースすることも可能にする。このトレースは、ブロックチェーン全体を通じて、ファイルの証拠保全を確認する。
例えば、ファイル内で示されている人の識別情報を保護するために、前のブロック内のファイルの一部が編集されるか、遮断されるか、または画素化される場合について考える。この場合、編集されたファイルを含んでいるブロックは、例えば、編集がどのように実行されたか、誰が編集を実行したか、編集が発生したタイムスタンプなどの、編集されたファイルに関連付けられたメタデータを含むであろう。このメタデータがハッシュされ、値を形成してよい。ブロックのメタデータが、前のブロック内の値を形成するためにハッシュされた情報と異なっているため、値は、互いに異なっており、復号されたときに回復されてよい。
1つの実施形態では、次のうちのいずれか1つまたは複数が発生した場合に、現在のブロックの値を形成するように、前のブロックの値が更新されてよい(例えば、新しいハッシュ値が計算されてよい)。新しいハッシュ値は、この実施形態例では、以下に示された情報のすべてまたは一部をハッシュすることによって計算されてよい。
a)ファイルがいずれかの方法で処理された場合(例えば、ファイルが編集されたか、コピーされたか、変更されたか、アクセスされたか、またはその他の動作が実行された場合)に、新しいSHA-2によって計算されたハッシュ値
b)ファイルの新しいストレージ位置
c)ファイルに関連付けられている識別された新しいメタデータ
d)あるブロックチェーンの参加者から別のブロックチェーンの参加者へのファイルのアクセスまたは制御の移動
図7Dは、1つの実施形態例に従って、ブロックチェーン790内のブロックの構造を表すことができるブロックの実施形態を示している。ブロック(ブロック)は、ヘッダー772、ファイル774、および値776を含んでいる。
ヘッダー772は、本明細書において説明された、前のブロック(ブロックi-1)のハッシュ値、および例えば情報の種類のいずれかであってよい、追加の参照情報(例えば、参照、特性、パラメータなどを含んでいるヘッダー情報)を含む。すべてのブロックは、当然ながらジェネシス・ブロックを除いて、前のブロックのハッシュを参照する。前のブロックのハッシュ値は、単に前のブロック内のヘッダーのハッシュであるか、またはファイルおよびメタデータを含む、前のブロック内の情報のすべてもしくは一部のハッシュであってよい。
ファイル774は、データ1、データ2、...、データNなどの複数のデータを順に含んでいる。データは、データに関連付けられた内容または特性あるいはその両方を記述するメタデータ1、メタデータ2、...、メタデータNでタグ付けされる。例えば、データごとのメタデータは、データのタイムスタンプ、データのプロセス、データに示された人またはその他の内容を示しているキーワード、またはファイルの有効性および内容を全体として確立し、特に、例えば以下で説明される実施形態に関連して説明されるように、デジタル証拠を使用するのに役立つことができるその他の特徴、あるいはその組み合わせを示すための情報を含んでよい。メタデータに加えて、各データは、改ざん、ファイル内のギャップ、およびファイル全体の連続的な参照を防ぐために、前のデータへの参照(参照、参照、...、参照)でタグ付けされてよい。
メタデータが(例えば、スマート・コントラクトを介して)データに割り当てられた後に、ハッシュを変更せずにメタデータを変更することはできず、ハッシュの変更は、無効であると容易に識別され得る。したがって、メタデータは、ブロックチェーン内の参加者による使用のためにアクセスされてよい、情報のデータ・ログを作成する。
値776は、前に説明された情報の種類のいずれかに基づいて計算されたハッシュ値またはその他の値である。例えば、いずれかの特定のブロック(ブロック)の場合、そのブロックの値は、そのブロックに対して実行された処理(例えば、新しいハッシュ値、新しいストレージ位置、関連するファイルの新しいメタデータ、制御もしくはアクセスの移動、識別子、またはその他の動作もしくは追加される情報)を反映するように更新されてよい。各ブロック内の値が、ファイルおよびヘッダーのデータのメタデータから分離しているように示されているが、別の実施形態では、値は、このメタデータに部分的または全体的に基づいてよい。
ブロックチェーン770が形成された後に、いずれかの時点で、ブロック全体にわたる値のトランザクション履歴に関してブロックチェーンに問い合わせることによって、ファイルの変更不可能な証拠保全が取得されてよい。この問い合わせ手順または追跡手順は、最後に含まれたブロック(例えば、最後の(N番目の)ブロック)の値を復号することから開始してよく、その後、ジェネシス・ブロックに達し、元のファイルが回復されるまで、他のブロックの値を復号し続ける。復号は、さらに各ブロックでヘッダーおよびファイルならびに関連するメタデータを復号することを含んでもよい。
復号は、各ブロックで行われた暗号化の種類に基づいて実行される。この復号は、秘密鍵、公開鍵、または公開鍵と秘密鍵のペアの使用を含んでよい。例えば、非対称暗号化が使用される場合、ブロックチェーンの参加者またはネットワーク内のプロセッサが、既定のアルゴリズムを使用して公開鍵および秘密鍵のペアを生成してよい。公開鍵および秘密鍵は、何らかの数学的関係によって互いに関連付けられる。公開鍵は、他のユーザからメッセージを受信するためのアドレス(例えば、IPアドレスまたは自宅住所)として機能するように、パブリックに配布されてよい。秘密鍵は、秘密に保たれ、他のブロックチェーンの参加者に送信されるメッセージにデジタル署名するために使用される。署名は、受信者が送信者の公開鍵を使用して検証することができるように、メッセージに含まれる。このようにして、受信者は、送信者のみがこのメッセージを送信できたということを確信することができる。
鍵のペアを生成することは、ブロックチェーンにアカウントを作成することに類似しているが、実際は、どこにも登録する必要はない。また、ブロックチェーンに対して実行されたすべてのトランザクションが、秘密鍵を使用して送信者によってデジタル署名される。この署名は、アカウントの所有者のみが(スマート・コントラクトによって決定された許可の範囲内である場合に)ブロックチェーンのファイルを追跡して処理することができるということを保証する。
図8Aおよび8Bは、本明細書に組み込まれて使用されてよい、ブロックチェーンの追加の使用事例を示している。特に、図8Aは、機械学習(人工知能)データを格納するブロックチェーン810の例800を示している。機械学習は、新しいデータに対する正確な予測のための予測モデルを構築するために、大量の履歴データ(またはトレーニング・データ)に依存する。機械学習ソフトウェア(例えば、ニューラル・ネットワークなど)は、多くの場合、非直感的パターンを発見するために、数百万レコードを取捨選択することができる。
図8Aの例では、ホスト・プラットフォーム820が、アセット830の予測監視のための機械学習モデルを構築してデプロイする。ここで、ホスト・プラットフォーム820は、クラウド・プラットフォーム、工業用サーバ、Webサーバ、パーソナル・コンピュータ、ユーザ・デバイスなどであってよい。アセット830は、航空機、機関車、タービン、医療機器、石油ガス機器、ボート、船、車両などの、任意の種類のアセット(例えば、機械または機器など)であることができる。別の例として、アセット830は、株式、通貨、デジタル・コイン、保険などの、無形のアセットであってよい。
ブロックチェーン810は、機械学習モデルのトレーニング・プロセス802およびトレーニング済み機械学習モデルに基づく予測プロセス804の両方を大幅に改善するために使用され得る。例えば、802では、データを収集するためにデータ科学者/技術者またはその他のユーザを必要とするのではなく、アセット830自体によって(または、図示されていない中間物を介して)、ブロックチェーン810に関する履歴データが格納されてよい。これによって、予測モデルのトレーニングを実行するときにホスト・プラットフォーム820によって必要とされる収集時間を大幅に減らすことができる。例えば、スマート・コントラクトを使用して、データを、元の場所からブロックチェーン810に真っすぐに、直接かつ確実に転送することができる。スマート・コントラクトは、ブロックチェーン810を使用して、収集されたデータのセキュリティおよび所有権を保証することによって、アセットから、機械学習モデルを構築するためにデータを使用する個人に、データを直接送信することができる。これによって、アセット830間のデータの共有を可能にする。
収集されたデータは、合意メカニズムに基づいてブロックチェーン810に格納されてよい。合意メカニズムは、記録されているデータが検証されており、正確であることを保証するために、(許可されたノードを)制御する。記録されたデータは、タイムスタンプが付与され、暗号によって署名されており、変更不可能である。したがって、記録されたデータは、監査可能、透過的、かつ安全である。ブロックチェーンに直接書き込むIoTデバイスを追加することによって、特定の場合(すなわち、サプライ・チェーン、医療、物流などの場合)に、データが記録される頻度を増やし、その精度を向上させることができる。
さらに、収集されたデータに対する機械学習モデルのトレーニングは、ホスト・プラットフォーム820による一連の改良およびテストを必要とし得る。各改良およびテストは、機械学習モデルの知識を拡張するのに役立つように、追加データまたは以前に考慮されなかったデータに基づいてよい。802では、ホスト・プラットフォーム820によって、異なるトレーニング・ステップおよびテスト・ステップ(および関連するデータ)がブロックチェーン810に格納されてよい。機械学習モデルの各改良(例えば、変数、重みなどにおける変更)は、ブロックチェーン810に格納されてよい。これによって、モデルがどのようにトレーニングされたか、およびモデルをトレーニングするためにどのデータが使用されたかの検証可能な証明を提供する。さらに、ホスト・プラットフォーム820が最終的なトレーニング済みモデルを実現した場合、得られたモデルがブロックチェーン810に格納されてよい。
モデルがトレーニングされた後に、そのモデルは、活動中の環境にデプロイされてよく、最終的なトレーニング済み機械学習モデルの実行に基づく予測/決定を行うことができる。例えば、804で、機械学習モデルは、航空機、風力タービン、医療機械などのアセットのための状態監視保全(CBM:condition-based maintenance)に使用されてよい。この例では、アセット830からフィードバックされたデータが機械学習モデルに入力され、故障イベント、エラー・コードなどのイベント予測を行うために使用されてよい。ホスト・プラットフォーム820で機械学習モデルの実行によって行われた決定は、監査可能/検証可能な証明を提供するために、ブロックチェーン810に格納されてよい。1つの非限定的な例として、機械学習モデルは、アセット830の部品での将来の停止/故障を予測し、その部品を交換するように警告または通知を作成してよい。この決定の背後にあるデータが、ホスト・プラットフォーム820によってブロックチェーン810に格納されてよい。1つの実施形態では、本明細書において説明されたか、または示されたか、あるいはその両方である特徴または動作あるいはその両方が、ブロックチェーン810で、またはブロックチェーン810に関して発生することができる。
ブロックチェーンの新しいトランザクションが新しいブロックに一緒に集められ、既存のハッシュ値に追加されることができる。次に、このハッシュ値が暗号化されて、新しいブロックの新しいハッシュを生成する。この新しいハッシュが、トランザクションが暗号化されるときなどに、トランザクションの次のリストに追加される。この結果は、先行するすべてのブロックのハッシュ値をそれぞれ含んでいるブロックのチェーンである。これらのブロックを格納するコンピュータは、ブロックのハッシュ値を定期的に比較し、それらのコンピュータがすべて合意していることを確認する。合意していないすべてのコンピュータは、問題を引き起こしているレコードを破棄する。この方法は、ブロックチェーンの改ざん防止を保証することに適しているが、完璧ではない。
このシステムを不正に操作する1つの方法は、不正なユーザが、ハッシュを変更しないような方法で、トランザクションのリストを自分の都合の良いように変更することである。これは、総当たり攻撃によって実行されることができ、言い換えると、レコードを変更し、結果を暗号化し、ハッシュ値が同じであるかどうかを確認することによって、実行されることができる。ハッシュ値が同じでない場合、一致するハッシュを見つけるまで、何度も繰り返して試みる。ブロックチェーンのセキュリティは、通常のコンピュータが、宇宙の年齢などの、全く非実用的な時間的尺度にわたってしかこの種の総当たり攻撃を実行できないという考えに基づく。それに対して、量子コンピュータは非常に高速(数千倍高速)であり、したがって、非常に大きい脅威をもたらす。
図8Bは、量子コンピューティング攻撃に対して保護するために量子鍵配送(QKD:quantum key distribution)を実装する量子セキュアなブロックチェーン852の例850を示している。この例では、ブロックチェーン・ユーザは、QKDを使用して互いの識別情報を検証することができる。この検証では、光子などの量子的粒子を使用して情報を送信し、この情報は、破壊することなく盗聴者によってコピーされることが不可能である。このようにして、送信者および受信者が、ブロックチェーンを介して、互いの識別情報を確認することができる。
図8Bの例では、4人のユーザ(854、856、858、および860)が存在している。ユーザのペアの各々は、ユーザ自身の間で秘密鍵862(すなわち、QKD)を共有することができる。この例には4つのノードが存在するため、ノードの6つのペアが存在し、したがって、QKDAB、QKDAC、QKDAD、QKDBC、QKDBD、およびQKDCDを含む6つの異なる秘密鍵862が使用される。各ペアは、光子などの量子的粒子を使用して情報を送信することによってQKDを作成することができ、この情報は、破壊することなく盗聴者によってコピーされることが不可能である。このようにして、ユーザのペアが互いの識別情報を確認することができる。
ブロックチェーン852の動作は、(i)トランザクションの作成、および(ii)新しいトランザクションを集めるブロックの構築という2つの手順に基づく。新しいトランザクションは、従来のブロックチェーン・ネットワークと同様に作成されてよい。各トランザクションは、送信者、受信者、作成時間、転送される量(または値)、送信者が操作のための資金を持っていることを正当化する参照トランザクションのリストに関する情報などを含んでよい。次に、このトランザクション・レコードは、すべての他のノードに送信され、未確認トランザクションのプールに入力される。ここで、2人の関係者(すなわち、854~860のうちのユーザのペア)が、共有秘密鍵862(QKD)を提供することによって、トランザクションを認証する。この量子署名は、すべてのトランザクションに添付され、改ざんを極めて困難にすることができる。各ノードは、ブロックチェーン852のローカル・コピーに関してトランザクションのエントリをチェックし、各トランザクションが十分な資金を持っていることを検証する。しかし、トランザクションはまだ確認されていない。
ブロックに対して従来のマイニング・プロセスを実行するのではなく、ブロードキャスト・プロトコルを使用して、分散された方法でブロックが作成されてよい。既定の期間(例えば、数秒、数分、数時間など)に、ネットワークがブロードキャスト・プロトコルをいずれかの未確認トランザクションに適用してよく、それによって、トランザクションの正しいバージョンに関してビザンチン合意(合意)を達成する。例えば、各ノードは、プライベートな値(その特定のノードのトランザクション・データ)を所有してよい。1回目に、ノードは、プライベートな値を互いに送信する。その後、ノードは、前回他のノードから受信した情報を伝達する。ここで、本物のノードが、新しいブロック内のトランザクションの完全なセットを作成することができる。この新しいブロックは、ブロックチェーン852に追加されることができる。1つの実施形態では、本明細書において説明されたか、または示されたか、あるいはその両方である特徴または動作あるいはその両方が、ブロックチェーン852で、またはブロックチェーン852に関して発生することができる。
図9は、本明細書において説明されたか、または示されたか、あるいはその両方である実施形態例のうちの1つまたは複数をサポートする例示的なシステム900を示している。システム900は、他の多数の汎用または特殊用途のコンピューティング・システム環境または構成で運用できるコンピュータ・システム/サーバ902を備えている。コンピュータ・システム/サーバ902と共に使用するのに適し得る周知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例としては、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル・コンシューマ・エレクトロニクス、ネットワークPC、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、およびこれらの任意のシステムまたはデバイスを含む分散クラウド・コンピューティング環境などが挙げられるが、これらに限定されない。
コンピュータ・システム/サーバ902は、コンピュータ・システムによって実行されているプログラム・モジュールなどの、コンピュータ・システムによって実行可能な命令との一般的な関連において説明されてよい。通常、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含んでよい。コンピュータ・システム/サーバ902は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散クラウド・コンピューティング環境で実行されてよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム・ストレージ媒体に配置されてよい。
図9に示すように、クラウド・コンピューティング・ノード900内のコンピュータ・システム/サーバ902は、汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム/サーバ902のコンポーネントは、1つまたは複数のプロセッサまたはプロセッシング・ユニット904、システム・メモリ906、およびシステム・メモリ906を含むさまざまなシステム・コンポーネントをプロセッサ904に結合するバスを含んでよいが、これらに限定されない。
バスは、メモリ・バスまたはメモリ・コントローラ、ペリフェラル・バス、アクセラレーテッド・グラフィックス・ポート、および任意のさまざまなバス・アーキテクチャを使用するプロセッサまたはローカル・バスを含む、任意の複数の種類のバス構造のうちの1つまたは複数を表す。例として、そのようなアーキテクチャは、ISA(Industry Standard Architecture)バス、MCA(Micro Channel Architecture)バス、EISA(Enhanced ISA)バス、VESA(Video Electronics Standards Association)ローカル・バス、およびPCI(Peripheral Component Interconnects)バスを含むが、これらに限定されない。
コンピュータ・システム/サーバ902は、通常、さまざまなコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム/サーバ902によってアクセスできる任意の使用可能な媒体であってよく、揮発性および不揮発性媒体、取り外し可能および取り外し不可の媒体を含む。システム・メモリ906は、1つの実施形態では、他の図のフロー図を実装する。システム・メモリ906は、ランダム・アクセス・メモリ(RAM:random access memory)910またはキャッシュ・メモリ912あるいはその両方などの、揮発性メモリの形態でのコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム/サーバ902は、その他の取り外し可能/取り外し不可、揮発性/不揮発性のコンピュータ・システム・ストレージ媒体をさらに含んでよい。単に例として、取り外し不可、不揮発性の磁気媒体(図示されておらず、通常は「ハード・ドライブ」と呼ばれる)に対する読み取りと書き込みを行うために、ストレージ・システム914を提供することができる。図示されていないが、取り外し可能、不揮発性の磁気ディスク(例えば、「フロッピー(R)・ディスク」)に対する読み取りと書き込みを行うための磁気ディスク・ドライブ、およびCD-ROM、DVD-ROM、またはその他の光媒体などの取り外し可能、不揮発性の光ディスクに対する読み取りと書き込みを行うための光ディスク・ドライブを提供することができる。そのような例では、それぞれを、1つまたは複数のデータ媒体インターフェイスによってバスに接続することができる。下で詳細に示され、説明されるように、メモリ906は、本出願のさまざまな実施形態の機能を実行するように構成された一連の(例えば、少なくとも1つの)プログラム・モジュールを備える少なくとも1つのプログラム製品を含んでよい。
例えば、一連の(少なくとも1つの)プログラム・モジュール918を含んでいるプログラム/ユーティリティ916がメモリ906に格納されてよいが、これに限定されず、オペレーティング・システム、1つまたは複数のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データも格納されてよい。オペレーティング・システム、1つまたは複数のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データまたはこれらの組み合わせの各々は、ネットワーク環境の実装を含んでよい。プログラム・モジュール918は、通常、本明細書に記載された本出願のさまざまな実施形態の機能または方法あるいはその両方を実行する。
当業者によって理解されるように、本出願の態様は、システム、方法、またはコンピュータ・プログラム製品として具現化されてよい。したがって、本出願の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態(ファームウェア、常駐ソフトウェア、マイクロコードなどを含む)、またはソフトウェアの態様とハードウェアの態様を組み合わせる実施形態の形態を取ってよく、これらはすべて、本明細書では、一般に「回路」、「モジュール」、または「システム」と呼ばれてよい。さらに、本出願の形態は、コンピュータ可読プログラム・コードが具現化されている1つまたは複数のコンピュータ可読媒体において具現化されたコンピュータ・プログラム製品の形態を取ってよい。
また、コンピュータ・システム/サーバ902は、キーボード、ポインティング・デバイス、ディスプレイ922などの1つまたは複数の外部デバイス920、ユーザがコンピュータ・システム/サーバ902と情報をやりとりできるようにする1つまたは複数のデバイス、またはコンピュータ・システム/サーバ902が1つまたは複数の他のコンピューティング・デバイスと通信できるようにする任意のデバイス(例えば、ネットワーク・カード、モデムなど)、あるいはその組み合わせと通信することもできる。このような通信は、I/Oインターフェイス924を介して行うことができる。さらに、コンピュータ・システム/サーバ902は、ローカル・エリア・ネットワーク(LAN:local area network)、一般的な広域ネットワーク(WAN:wide area network)、またはパブリック・ネットワーク(例えば、インターネット)、あるいはその組み合わせなどの1つまたは複数のネットワークと、ネットワーク・アダプタ926を介して通信することができる。図示されているように、ネットワーク・アダプタ926は、バスを介してコンピュータ・システム/サーバ902の他のコンポーネントと通信する。図示されていないが、その他のハードウェア・コンポーネントまたはソフトウェア・コンポーネントあるいはその両方を、コンピュータ・システム/サーバ902と併用できるということが理解されるべきである。その例として、マイクロコード、デバイス・ドライバ、冗長プロセッシング・ユニット、外部ディスク・ドライブ・アレイ、RAIDシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが挙げられるが、これらに限定されない。
システム、方法、および非一過性コンピュータ可読媒体のうちの少なくとも1つの実施形態例が添付の図面において示され、前述の詳細な説明において説明されたが、本出願が、開示された実施形態に限定されず、以下の特許請求の範囲によって示され、定義されているように、多数の再配置、変更、および置き換えを行うことができるということが理解されるであろう。例えば、さまざまな図のシステムの機能は、本明細書に記載されたモジュールまたはコンポーネントのうちの1つまたは複数によって、あるいは分散アーキテクチャにおいて実行することができ、送信器、受信器、またはその両方のペアを含んでよい。例えば、個々のモジュールによって実行される機能の全部または一部は、それらのモジュールのうちの1つまたは複数によって実行されてよい。さらに、本明細書に記載された機能は、さまざまな時間に、さまざまなイベントに関して、モジュールまたはコンポーネントの内部または外部で、実行されてよい。また、さまざまなモジュールの間で送信される情報は、データ・ネットワーク、インターネット、音声ネットワーク、インターネット・プロトコル・ネットワーク、無線デバイス、有線デバイスのうちの少なくとも1つを介して、または複数のプロトコルを介して、あるいはその組み合わせを介して、モジュール間で送信され得る。また、モジュールのいずれかによって送信または受信されるメッセージは、直接的に、または他のモジュールのうちの1つまたは複数を介して、あるいはその両方によって、送信または受信されてよい。
当業者は、「システム」を、パーソナル・コンピュータ、サーバ、コンソール、PDA(personal digital assistant)、携帯電話、タブレット・コンピューティング・デバイス、スマートフォン、または任意のその他の適切なコンピューティング・デバイス、あるいはデバイスの組み合わせとして具現化できるということを、理解するであろう。「システム」によって実行されている前述の機能を提示することは、本出願の範囲を限定するように全く意図されておらず、多くの実施形態のうちの1つの例を提供するよう意図されている。実際に、本明細書で開示された方法、システム、および装置は、計算技術に一致する局所的な分散された形態で実装されてよい。
本明細書において説明されたシステムの特徴の一部が、それらの実装の独立性を特により強調するために、モジュールとして提示されていることに、注意するべきである。例えば、モジュールは、カスタム超大規模集積(VLSI:very large-scale integration)回路またはゲート・アレイ、論理チップなどの市販の半導体、トランジスタ、またはその他の個別のコンポーネントを備えているハードウェア回路として実装されてよい。モジュールは、フィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ論理、プログラマブル論理デバイス、グラフィックス・プロセッシング・ユニットなどの、プログラム可能なハードウェア・デバイスにおいて実装されてもよい。
モジュールは、さまざまな種類のプロセッサによって実行するために、ソフトウェアにおいて少なくとも部分的に実装されてもよい。例えば、実行可能コードの識別されたユニットは、例えばオブジェクト、プロシージャ、または関数として編成されてよいコンピュータ命令の1つまたは複数の物理的または論理的ブロックを備えてよい。それにもかかわらず、識別されたモジュールの実行可能によって、物理的に一緒に配置される必要はなく、異なる位置に格納された異種の命令を含んでよく、それらの命令は、論理的に一緒に結合された場合にモジュールを備え、モジュールの規定された目的を達成する。さらに、モジュールはコンピュータ可読媒体に格納されてよく、このコンピュータ可読媒体は、例えば、ハード・ディスク・ドライブ、フラッシュ・デバイス、ランダム・アクセス・メモリ(RAM)、テープ、またはデータの格納に使用される任意のその他の媒体であってよい。
実際に、実行可能コードのモジュールは、単一の命令であるか、または多くの命令であることができ、複数の異なるコード・セグメントにわたって、異なるプログラム間および複数のメモリ・デバイスにまたがって、分散されてもよい。同様に、操作可能なデータが、識別され、本明細書ではモジュール内で示されてよく、任意の適切な形態で具現化され、任意の適切な種類のデータ構造内で編成されてよい。操作可能なデータは、単一のデータ・セットとして収集されてよく、または異なるストレージ・デバイスを含む、異なる位置にわたって分散されてよく、システムまたはネットワーク上の単なる電子信号として、少なくとも部分的に存在してよい。
本明細書の図において概略的に説明され、示されているように、本出願のコンポーネントが、多種多様な異なる構成で配置および設計されてよいということが、容易に理解されるであろう。したがって、実施形態の詳細な説明は、請求される本出願の範囲を限定するよう意図されておらず、単に、本出願の選択された実施形態を表している。
当業者は、開示された順序とは異なる順序でステップを使用して、または開示された構成におけるハードウェア要素とは異なるハードウェア要素を使用して、あるいはその両方を使用して、前述の内容を実践できるということを、容易に理解するであろう。したがって、本出願は、これらの好ましい実施形態に基づいて説明されたが、特定の変更、変形、および代替の構造が明白であるということは、当業者にとって明らかであろう。
本出願の好ましい実施形態が説明されたが、説明された実施形態が単なる例であり、それらの実施形態と同等のものおよびそれらの実施形態に対する変更の完全な範囲(例えば、プロトコル、ハードウェア・デバイス、ソフトウェア・プラットフォームなど)で考えた場合、本出願の範囲が添付の特許請求の範囲のみによって定義されるべきであるということが、理解されるべきである。

Claims (20)

  1. ブロックチェーンの前の一次ピアから前記一次ピアへのビュー変更を要求するビュー変更メッセージを受信するように構成されたネットワーク・インターフェイスと、
    前記受信されたビュー変更メッセージのメタデータに基づいて、前記ブロックチェーンの状態に対する変更が前記前の一次ピアを使用して処理中であることを識別し、受信されたビュー・データ・メッセージに基づいて、前記ブロックチェーンの前記状態に対する前記変更が、前記ブロックチェーンに対する最新の変更に対応するということを検証するように構成されたプロセッサとを備えている装置であって、
    前記ネットワーク・インターフェイスが、前記ブロックチェーンの前記状態に対する前記処理中の変更を含んでいる新しいビュー・メッセージを追従するピアに送信するようにさらに構成される、装置。
  2. 前記ネットワーク・インターフェイスが、1つのビュー・データ・メッセージのみの受信に応答して前記新しいビュー・メッセージを送信するように構成される、請求項1に記載の装置。
  3. 前記ブロックチェーンの前記状態に対する前記処理中の変更が、提案されたデータ・ブロックを含む、請求項1に記載の装置。
  4. 前記プロセッサが、前記ビュー変更メッセージが既定のしきい値数の前記追従するピアから受信されたことを検証するようにさらに構成される、請求項1に記載の装置。
  5. ビュー変更メッセージごとに、前記メタデータが、次のビュー番号および前記ブロックチェーンに対するハッシュされた変更を含む、請求項1に記載の装置。
  6. 前記ビュー・データ・メッセージが複数の準備メッセージを含み、前記準備メッセージが他のピアから前記追従するピアによって受信される、請求項1に記載の装置。
  7. 前記プロセッサが、前記ブロックチェーンの前記状態に対する前記処理中の変更が、前記ビュー・データ・メッセージ内に格納された既定の数の前記署名された準備メッセージに含まれているということを検証するように構成される、請求項6に記載の装置。
  8. 前記ブロックチェーンの状態に対する変更が、前記現在の一次ピアを使用して処理中であるということを識別することと、次のビュー番号および前記ブロックチェーンの前記状態に対する前記処理中の変更のハッシュを含んでいるビュー変更メッセージを生成することとをさらに含む、請求項1に記載の装置。
  9. 前記プロセッサが、前記ブロックチェーンの前記状態に対する前記処理中の変更に合意する前記ブロックチェーンの他の追従するピアの署名を、前記ビュー変更メッセージ内に格納するようにさらに構成される、請求項8に記載の装置。
  10. 実用的ビザンチン・フォールト・トレランス(pBFT)合意の準備段階中に、前記ブロックチェーンの前記状態に対する前記処理中の変更および前記署名が収集される、請求項8に記載の装置。
  11. 前記プロセッサが、前記現在の一次ピアから受信された事前準備メッセージに基づいて前記ブロックチェーンの前記状態に対する前記処理中の変更を識別するように構成される、請求項8に記載の装置。
  12. 前記一次ピアから、ブロックチェーンに追加されるよう提案されたデータを含んでいる事前準備メッセージを受信するようにさらに構成された前記ネットワーク・インターフェイスと、
    前記ブロックチェーンに追加されるよう前記提案されたデータのハッシュおよび前記合意ピアの署名を含んでいる準備メッセージを生成すること、前記合意ピアのハッシュ・パズルを前記準備メッセージに追加すること、ならびに前記ハッシュ・パズルを含む前記準備メッセージを前記ブロックチェーンの複数の他の合意ピアに送信することを実行するようにさらに構成された前記プロセッサとをさらに備える、請求項1に記載の装置。
  13. 前記プロセッサが、前記他の合意ピアから受信された準備メッセージに基づいて、既定のしきい値数の前記他の合意ピアが、前記ブロックチェーンに追加されるよう前記提案されたデータに合意するということを決定するようにさらに構成される、請求項12に記載の装置。
  14. 前記プロセッサが、前記準備メッセージに追加された前記ハッシュ・パズルに対する解を含んでいるコミット・メッセージを生成し、前記コミット・メッセージを前記複数の他の合意ピアに送信するようにさらに構成される、請求項12に記載の装置。
  15. 前記コミット・メッセージが前記合意ピアの署名を含まない、請求項12に記載の装置。
  16. 前記プロセッサが、既定の秘密値のハッシュを介して前記ハッシュ・パズルを生成するように構成される、請求項12に記載の装置。
  17. 前記プロセッサが、前記他の合意ピアから準備メッセージを受信するようにさらに構成され、前記受信された準備メッセージが、前記他の各合意ピアによって追加されたハッシュ・パズルを含む、請求項12に記載の装置。
  18. 一次ピアの方法であって、
    ブロックチェーンの前の一次ピアから前記一次ピアへのビュー変更を要求するビュー変更メッセージを受信することと、
    前記受信されたビュー変更メッセージのメタデータに基づいて、前記ブロックチェーンの状態に対する変更が前記前の一次ピアを使用して処理中であることを識別することと、
    受信されたビュー・データ・メッセージに基づいて、前記ブロックチェーンの前記状態に対する前記変更が、前記ブロックチェーンに対する最新の変更に対応するということを検証することと、
    前記ブロックチェーンの前記状態に対する前記処理中の変更を含んでいる新しいビュー・メッセージを追従するピアに送信することとを含む、方法。
  19. 前記送信することが、1つのビュー・データ・メッセージのみの受信に応答して前記新しいビュー・メッセージを送信することを含む、請求項18に記載の方法。
  20. 前記ブロックチェーンの前記状態に対する前記処理中の変更が、提案されたデータ・ブロックを含む、請求項18に記載の方法。
JP2022557974A 2020-04-17 2021-04-13 ブロックチェーンのより高速なビュー変更 Pending JP2023520859A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/851,537 US11250021B2 (en) 2020-04-17 2020-04-17 Faster view change for blockchain
US16/851,537 2020-04-17
PCT/IB2021/053029 WO2021209890A1 (en) 2020-04-17 2021-04-13 Faster view change for blockchain

Publications (1)

Publication Number Publication Date
JP2023520859A true JP2023520859A (ja) 2023-05-22

Family

ID=78082226

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022557974A Pending JP2023520859A (ja) 2020-04-17 2021-04-13 ブロックチェーンのより高速なビュー変更

Country Status (10)

Country Link
US (3) US11250021B2 (ja)
JP (1) JP2023520859A (ja)
KR (1) KR20220149702A (ja)
CN (1) CN115699054A (ja)
AU (1) AU2021254870B2 (ja)
CA (1) CA3171999A1 (ja)
DE (1) DE112021000608T5 (ja)
GB (1) GB2610107A (ja)
IL (1) IL296314A (ja)
WO (1) WO2021209890A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10713133B2 (en) * 2018-06-11 2020-07-14 Vmware, Inc. Linear view-change BFT
CN111526216B (zh) * 2020-07-03 2020-09-22 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和***
US11080412B1 (en) * 2020-08-20 2021-08-03 Spideroak, Inc. Efficiently computing validity of a block chain
CN114760198B (zh) * 2022-01-17 2023-03-24 清华大学 一种基于区块链网络的共识方法、装置及***
CN114466034B (zh) * 2022-03-21 2022-09-02 北京航空航天大学 一种基于匿名主节点的区块链共识方法
CN114900529A (zh) * 2022-06-09 2022-08-12 上海万向区块链股份公司 区块敲定方法及***
CN114826592B (zh) * 2022-06-22 2022-10-14 腾讯科技(深圳)有限公司 基于区块链的密钥生成方法、装置、电子设备和可读介质
CN117033146B (zh) * 2023-10-10 2023-12-08 北京安天网络安全技术有限公司 指定共识合约执行进程的识别方法、装置、设备及介质

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106445711B (zh) 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法
US10565570B2 (en) 2016-09-27 2020-02-18 The Toronto-Dominion Bank Processing network architecture with companion database
US10713963B2 (en) 2017-05-25 2020-07-14 International Business Machines Corporation Managing lifelong learner events on a blockchain
US10761877B2 (en) 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
US10887090B2 (en) * 2017-09-22 2021-01-05 Nec Corporation Scalable byzantine fault-tolerant protocol with partial tee support
CA2995772A1 (en) 2018-02-21 2019-08-21 Beijing Tiande Technologies Limited A method of block building based on byzantine consensus via four rounds of communication
CN110569395A (zh) 2018-05-18 2019-12-13 北京天德科技有限公司 一种稳定可靠的区块链拜占庭共识流程设计方法
CN109246194B (zh) 2018-08-13 2021-06-08 佛山市顺德区中山大学研究院 基于多领导节点的实用拜占庭容错区块链共识方法及***
CN109167661B (zh) 2018-09-27 2021-04-13 福建福链科技有限公司 一种应用于联盟链的拜占庭容错共识方法及终端
CN109246122A (zh) 2018-09-29 2019-01-18 上海海事大学 一种基于谣言传播协议的拜占庭容错区块链生成方法
CA3041463C (en) 2018-11-07 2020-08-25 Alibaba Group Holding Limited Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization
SG11201906834SA (en) * 2018-12-13 2019-08-27 Alibaba Group Holding Ltd Achieving consensus among network nodes in a distributed system
CN109981565B (zh) 2019-01-29 2021-10-15 广州中国科学院软件应用技术研究所 基于Meta-BFT共识机制的区块链平台及实现方法
WO2019170169A2 (en) * 2019-06-05 2019-09-12 Alibaba Group Holding Limited Consensus system and method
CN110730204B (zh) * 2019-09-05 2022-09-02 创新先进技术有限公司 区块链网络中删除节点的方法和区块链***
US20210099312A1 (en) * 2019-09-27 2021-04-01 Cypherium Blockchain Inc. Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system

Also Published As

Publication number Publication date
CA3171999A1 (en) 2021-10-21
CN115699054A (zh) 2023-02-03
WO2021209890A1 (en) 2021-10-21
US11775556B2 (en) 2023-10-03
US11250021B2 (en) 2022-02-15
US20210326352A1 (en) 2021-10-21
IL296314A (en) 2022-11-01
AU2021254870B2 (en) 2024-05-30
US20230409598A1 (en) 2023-12-21
DE112021000608T5 (de) 2022-12-01
GB202217087D0 (en) 2022-12-28
US20220138225A1 (en) 2022-05-05
AU2021254870A1 (en) 2022-09-22
GB2610107A (en) 2023-02-22
KR20220149702A (ko) 2022-11-08

Similar Documents

Publication Publication Date Title
AU2020414467B2 (en) Partially-ordered blockchain
AU2021254870B2 (en) Faster view change for blockchain
US11368285B2 (en) Efficient threshold storage of data object
JP2022541048A (ja) ブロックチェーンを構成するためのセキュリティ層
US11489663B2 (en) Correlation-based hash tree verification
US11580098B2 (en) Multi-client transaction validation
US11379472B2 (en) Schema-based pruning of blockchain data
US11275859B2 (en) Preservation of privacy in large datasets
US20220138550A1 (en) Blockchain for artificial intelligence training
US11343313B1 (en) Fault tolerant periodic leader rotation for blockchain
JP2023524715A (ja) ネットワーク間の識別情報プロビジョニング
JP2023520632A (ja) データの保護のためのノイズ・トランザクション
JP2023530594A (ja) 分散型データベースにおける許可されたイベント処理
US20230208638A1 (en) Future asset reclamation via blockchain
US11856092B2 (en) Limiting data availability on distributed ledger
US11847234B2 (en) Verifiable training of model in untrusted environment
JP2023551458A (ja) Oprfを介したブロックチェーンネットワークにおける鍵再生
US20230091686A1 (en) Digital asset platform with hsm verification
US11343085B2 (en) Threshold encryption for broadcast content
JP2023551160A (ja) Dltネットワークの自動化されたマージ
JP2023520634A (ja) 文脈完全性の維持
US20210314398A1 (en) Preservation of channel metadata
WO2023041995A1 (en) Privacy-preserving state reference

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221226

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230925