JP6732321B2 - 分散システムにおけるネットワークノードに対する回復処理の実行 - Google Patents

分散システムにおけるネットワークノードに対する回復処理の実行 Download PDF

Info

Publication number
JP6732321B2
JP6732321B2 JP2019540596A JP2019540596A JP6732321B2 JP 6732321 B2 JP6732321 B2 JP 6732321B2 JP 2019540596 A JP2019540596 A JP 2019540596A JP 2019540596 A JP2019540596 A JP 2019540596A JP 6732321 B2 JP6732321 B2 JP 6732321B2
Authority
JP
Japan
Prior art keywords
message
network
node
network node
valid
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.)
Active
Application number
JP2019540596A
Other languages
English (en)
Other versions
JP2020516105A (ja
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.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
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 Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of JP2020516105A publication Critical patent/JP2020516105A/ja
Application granted granted Critical
Publication of JP6732321B2 publication Critical patent/JP6732321B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/13—Linear codes
    • H03M13/15—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes
    • H03M13/151—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes using error location or error correction polynomials
    • H03M13/154—Error and erasure correction, e.g. by using the error and erasure locator or Forney polynomial
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/373—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35 with erasure correction and erasure determination, e.g. for packet loss recovery or setting of erasures for the decoding of Reed-Solomon codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Pure & Applied Mathematics (AREA)
  • Algebra (AREA)
  • Power Engineering (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本開示は、分散システムにおけるネットワークノードに対する回復処理の実行に関する。
分散台帳システム(DLS: Distributed ledger system)は、コンセンサスネットワークおよび/またはブロックチェーンネットワークと呼ばれることも可能であり、参加エンティティが安全かつ不変にデータを格納することを可能にする。DLSは、一般に、いずれかの特定のユーザ事例を参照することなく、ブロックチェーンネットワークと呼ばれる。ブロックチェーンネットワークの例は、公開ブロックチェーンネットワーク、プライベートブロックチェーンネットワーク、およびコンソーシアムブロックチェーンネットワークを含むことができる。公開ブロックチェーンネットワークは、全てのエンティティがDLSを使用してコンセンサス処理に参加することに対して開かれている。プライベートブロックチェーンネットワークは、読み書き許可を中心に制御する特定のエンティティに提供される。コンソーシアムブロックチェーンネットワークは、コンセンサス処理を制御するエンティティの選択グループに提供され、アクセス制御層を含む。
コンセンサスメカニズムは、分散ブロックチェーンシステムの主要な構成要素である。コンセンサスメカニズムは、分散処理またはシステムの間の単一データ値に対する合意を実現するために使用されるコンピュータサイエンスにおける処理である。コンセンサスメカニズムは、複数の信頼できないノードを含むネットワークにおける信頼性を実現するように設計される。コンセンサス問題として知られるこの問題を解決することは、分散コンピューティングおよびマルチエージェントシステムにおいて重要である。
ブロックチェーンは、ノード間の合意に達するためのコンセンサスメカニズムに依存する。ブロックチェーンは、ピアツーピア(P2P)ネットワーク上の分散コンピュータによって管理される非集中型データベースである。各ピアは、単一障害点(SPOF)を防ぐために台帳のコピーを維持する。更新および有効化は、全てのコピーに同時に反映される。
ブロックチェーンシステムのネットワークノード間のコンセンサスを行うために、いくつかの既存の技法が使用されることが可能であるが、コンセンサスを行うためのより効率的な解決策が有利になるであろう。
本明細書の実装形態は、分散システム(例えばブロックチェーンネットワーク)におけるコンセンサス問題に対処するためのコンピュータで実行される方法を含む。より具体的には、本明細書の実装形態は、分散システムにおけるネットワークノードに対する回復処理を行うことを対象とする。
いくつかの実装形態において、アクションは、ブロックチェーンネットワークのネットワークノードによってブロックチェーンネットワークのいくつかのネットワークノードに状態要求メッセージをブロードキャストすることであって、ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ブロードキャストすることと、いくつかのネットワークノードからネットワークノードによっていくつかの状態リプライメッセージを受け取ることであって、いくつかの状態リプライメッセージのそれぞれがシーケンス番号を含む、受け取ることと、状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいてネットワークノードによって対象シーケンス番号を識別することであって、いくつかの状態メッセージのそれぞれが同じシーケンス番号を含む、識別することと、ネットワークノードによって複数のネットワークノードに要求メッセージを送ることであって、要求メッセージが、いくつかのネットワークノードのそれぞれからのECHOメッセージを要求し、ECHOメッセージが、対象シーケンス番号を有する対象取引に対するいくつかのネットワークノード間のコンセンサスを実現するためにいくつかのネットワークノードのそれぞれによって送信されたメッセージであり、ECHOメッセージが、対象取引の一部、および複数のネットワークノードのそれぞれの署名を含む、送ることと、複数のネットワークノードからネットワークノードによっていくつかのECHOメッセージを受け取ることと、ネットワークノードによって複数のECHOメッセージからいくつかの有効なECHOメッセージを判断することであって、いくつかの有効なECHOメッセージのそれぞれが対象シーケンス番号を含む、判断することと、有効なECHOメッセージの数が所定の閾値を超過するとの判断に応答して、いくつかの有効なECHOメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることと、ネットワークノードが回復されたことを示すメッセージを複数のネットワークノードに、ネットワークノードによって送ることと、を含む。
他の実装形態は、コンピュータストレージデバイス上でエンコードされた方法のアクションを行うように構成された、対応するシステム、装置、およびコンピュータプログラムを含む。
これらおよび他の実装形態は、それぞれ任意選択で、以下の特徴の1つまたは複数を含む。
以下の特徴のいずれかと組み合わせ可能であり、いくつかのネットワークノードが、1次ノードおよび1つまたは複数のバックアップノードを含む、第1の特徴。
以下の特徴のいずれかと組み合わせ可能であり、ネットワークノードが、1次ノードまたはバックアップノードである、第2の特徴。
以下の特徴のいずれかと組み合わせ可能であり、要求メッセージが、対象シーケンス番号を含む、第3の特徴。
以下の特徴のいずれかと組み合わせ可能であり、ネットワークノードにECHOメッセージを送る前に、このネットワークノード以外のいくつかのネットワークノードのそれぞれが要求メッセージを検証する、第4の特徴。
以下の特徴のいずれかと組み合わせ可能であり、マークル木を使用してECHOメッセージのそれぞれが有効であるかどうかをネットワークノードが検証する、第5の特徴。
以下の特徴のいずれかと組み合わせ可能であり、ECHOメッセージ内の署名が有効であるかどうかをネットワークノードがさらに検証する、第6の特徴。
以下の特徴のいずれかと組み合わせ可能であり、ECHOメッセージのそれぞれが、対象取引と関連付けられたいくつかの消去コード(EC)ブロックのうちの少なくとも1つをさらに含み、いくつかのECブロックが、対象取引を使用してECコードに従って生成される、第7の特徴。
以下の特徴のいずれかと組み合わせ可能であり、ネットワークノードが、いくつかの有効なECHOメッセージ内にあるいくつかのECブロックのサブセットを使用して対象取引を再構築する、第8の特徴。
以下の特徴のいずれかと組み合わせ可能であり、ネットワークノードが回復されたことを示すいくつかのネットワークノードへのメッセージが、いくつかの有効なECHOメッセージ内の署名のセット、および対象シーケンス番号を含む、第9の特徴。
本明細書は、1つまたは複数のプロセッサに連結され、1つまたは複数のプロセッサによって実行されると、本明細書で提供される方法の実装形態による動作を1つまたは複数のプロセッサに行わせる、1つまたは複数の非一時的コンピュータ可読記憶媒体に格納された命令を有する、1つまたは複数の非一時的コンピュータ可読記憶媒体も提供する。
本明細書は、本明細書で提供される方法を実行するためのシステムをさらに提供する。システムは、1つまたは複数のプロセッサと、1つまたは複数のプロセッサによって実行されると、本明細書で提供される方法の実装形態による動作を1つまたは複数のプロセッサに行わせる、コンピュータ可読記憶媒体に格納された命令を有する、1つまたは複数のプロセッサに連結されたコンピュータ可読記憶媒体と、を含む。
本明細書は、分散システムにおけるネットワークノード間のコンセンサスを実現するため、分散システムにおける1次ノードの変更を行うため、および分散システムにおけるネットワークノードに対する回復処理を行うため、の技法を含む改良されたコンセンサスメカニズムを開示する。説明されるコンセンサスメカニズムは、様々な用途において様々な長所を実現することができる。
例えば、下記で論じられるようなコンセンサス処理は、ブロックチェーンシステムの動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、説明されるコンセンサス処理は、ECコードに従って取引要求をいくつかの消去コード(EC)ブロックにコンバートすること、およびネットワークノードのそれぞれにECブロックのうちの1つを送ること、を含む。ECブロックは、元の取引要求よりサイズが小さい。したがって、完全な取引要求の代わりにECブロックをネットワークノードに送ることは、ブロックチェーンネットワークのネットワークノード間で送信されるデータブロックのサイズを低減させ、このことにより、ネットワーク帯域幅を節約し、ネットワーク負荷を低減させる。これは、ネットワークノードのメモリ空間との間で読み書きされるデータのサイズをさらに低減させ、このことにより、ネットワークノードのメモリ空間に対する負担を低減させ、全体的なブロックチェーンシステムの効率性を改善する。
さらに、本明細書は、コンセンサス処理の複数のフェーズに個々の重みを割り当てること、複数のフェーズの個々の重みに基づいて加重和を判断すること、および加重和に基づいて新しい1次ノードを判断することを含むエポック変更処理を説明する。ラウンドロビン方法の代わりの加重和に基づくエポック変更処理は、故障していない新しい1次ノードをタイムリに選ぶことを容易にすることができる。ラウンドロビン方法とは異なり、本明細書におけるエポック変更処理は、加重和に応じて新しい1次ノードを選択し、これは、故障していない新しい1次ノードを見つける際のレイテンシまたは遅延を低減させることができる。これは、ブロックチェーンサービスを提供する際に全体的なブロックチェーンシステムの効率性をさらに改善することができる。
さらに、本明細書は、新しい1次ノードとして使用されるネットワークノードによって状態要求メッセージを送ること、および他のネットワークノードから状態リプライメッセージを受け取ることなどの動作を含む回復処理を論じる。これらの動作は、故障しているネットワークノードの回復処理が、他の故障していないネットワークノード間のコンセンサス処理の正常動作に支障を来さないように行われる。これは、回復処理の複雑性を低減させることによって、故障しているネットワークノードを回復させるためのコンピューティングリソースおよびネットワークリソースを節約することを容易にする。
本明細書による方法は、本明細書で説明される態様および特徴の任意の組合せを含むことができるということが認知される。すなわち、本明細書による方法は、本明細書で具体的に説明される態様および特徴の組合せに限定されるのではなく、提供される態様および特徴の任意の組合せも含む。
本明細書の1つまたは複数の実装形態の詳細が、添付の図面および下記の説明において示される。本明細書の他の特徴および長所は、説明および図面から、また特許請求の範囲から明らかになるであろう。
本明細書の実装形態を実行するために使用されることが可能な環境の例を描写する図である。 本明細書の実装形態による概念アーキテクチャの例を描写する図である。 本明細書の実装形態に従って実行されることが可能なコンセンサス処理の例を描写する図である。 本明細書の実装形態に従って実行されることが可能なコンセンサス処理の例を描写する図である。 本明細書の実装形態によるハッシュ木の例を描写する図である。 本明細書の実装形態による分散システムのネットワークノード間で通信されるメッセージの例を描写する図である。 本明細書の実装形態による分散システムにおける1次ノードの変更を行う処理の例を描写する図である。 本明細書の実装形態による分散システムにおける1次ノードの変更を行う処理の例を描写する図である。 本明細書の実装形態による分散システムのネットワークノード間で通信されるメッセージの例を描写する図である。 本明細書の実装形態による分散システムにおけるネットワークノードの回復処理を行う処理の例を描写する図である。 本明細書の実装形態による分散システムにおけるネットワークノードの回復処理を行う処理の例を描写する図である。 本明細書の実装形態による分散システムのネットワークノード間で通信されるメッセージの例を描写する図である。 本明細書の実装形態によるコンセンサス装置のモジュールを示す図の例を描写する図である。 本明細書の実装形態によるコンセンサス装置のモジュールを示す図の例を描写する図である。 本明細書の実装形態による1次ノード変更装置のモジュールを示す図の例を描写する図である。 本明細書の実装形態による1次ノード変更装置のモジュールを示す図の例を描写する図である。 本明細書の実装形態による回復装置のモジュールを示す図の例を描写する図である。
様々な図面における同様の参照符号は、同様の要素を示す。
本明細書の実装形態は、分散システム(例えばブロックチェーンネットワーク)におけるコンセンサス問題に対処するためのコンピュータで実行される方法を含む。より具体的には、本明細書の実装形態は、分散システムにおけるネットワークノードに対する回復処理を行うことを対象とする。
いくつかの実装形態において、アクションは、ブロックチェーンネットワークのネットワークノードによってブロックチェーンネットワークのいくつかのネットワークノードに状態要求メッセージをブロードキャストすることであって、ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ブロードキャストすることと、いくつかのネットワークノードからネットワークノードによっていくつかの状態リプライメッセージを受け取ることであって、いくつかの状態リプライメッセージのそれぞれがシーケンス番号を含む、受け取ることと、状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいてネットワークノードによって対象シーケンス番号を識別することであって、いくつかの状態メッセージのそれぞれが同じシーケンス番号を含む、識別することと、ネットワークノードによって複数のネットワークノードに要求メッセージを送ることであって、要求メッセージが、いくつかのネットワークノードのそれぞれからのECHOメッセージを要求し、ECHOメッセージが、対象シーケンス番号を有する対象取引に対するいくつかのネットワークノード間のコンセンサスを実現するためにいくつかのネットワークノードのそれぞれによって送信されたメッセージであり、ECHOメッセージが、対象取引の一部、および複数のネットワークノードのそれぞれの署名を含む、送ることと、複数のネットワークノードからネットワークノードによっていくつかのECHOメッセージを受け取ることと、ネットワークノードによって複数のECHOメッセージからいくつかの有効なECHOメッセージを判断することであって、いくつかの有効なECHOメッセージのそれぞれが対象シーケンス番号を含む、判断することと、有効なECHOメッセージの数が所定の閾値を超過するとの判断に応答して、いくつかの有効なECHOメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることと、ネットワークノードが回復されたことを示すメッセージを複数のネットワークノードに、ネットワークノードによって送ることと、を含む。
本明細書の実装形態に対するさらなる背景を示すために、また上記で紹介されたように、(例えばピアツーピアノードで構成される)コンセンサスネットワークまたはブロックチェーンネットワークと呼ばれることも可能な分散台帳システム(DLS)は、参加エンティティが安全かつ不変に取引を行うこと、およびデータを格納することを可能にする。用語ブロックチェーンは、任意の特定のユースケースを参照することなく、全体的にDLSを指すために本明細書で使用される。上記で紹介されたように、ブロックチェーンネットワークは、公開ブロックチェーンネットワーク、プライベートブロックチェーンネットワーク、またはコンソーシアムブロックチェーンネットワークとして提供されることが可能である。
ブロックチェーンは、チェーンに格納された先の全ての取引との一貫性について、将来の取引が検証されるのを可能にする方式で取引を格納するデータ構造である。ブロックチェーンは、1つまたは複数のブロックを含む。チェーン内の各ブロックは、前のブロックの暗号学的ハッシュを含めることによって、チェーン内のブロックの直前の先のブロックにリンクされる。各ブロックは、タイムスタンプ、ブロック自体の暗号学的ハッシュ、および1つまたは複数の取引も含む。ブロックチェーンネットワークのノードによって既に検証された取引は、ハッシュされ、マークル木にエンコードされる。マークル木は、マークル木の葉ノードにあるデータがハッシュされるデータ構造であり、マークル木の各枝における全てのハッシュが、枝のルートにおいて結合される。この処理は、マークル木に沿って、マークル木の中の全てのデータを表すハッシュを格納する木全体のルートまで続く。木に格納された取引のものであるとされるハッシュは、ハッシュが木の構造と一致するものであるかどうかを判断することによって迅速に検証されることが可能である。
ブロックチェーンが取引を格納するためのデータ構造である一方で、ブロックチェーンネットワークは、1つまたは複数のブロックチェーン構造を管理、更新、および維持するコンピューティングノードのネットワークである。上記で紹介されたように、ブロックチェーンネットワークは、公開ブロックチェーンネットワーク、プライベートブロックチェーンネットワーク、またはコンソーシアムブロックチェーンネットワークとして提供されることが可能である。
公開ブロックチェーンネットワークにおいて、コンセンサス処理は、コンセンサスネットワークのノードによって制御される。例えば、何百、何千、何百万ものエンティティでさえ、公開ブロックチェーンネットワークにおいて連携することができ、これらのそれぞれが、公開ブロックチェーンネットワーク内で少なくとも1つのノードを動作させる。したがって、公開ブロックチェーンネットワークは、参加エンティティに対するパブリックネットワークと見なされることが可能である。いくつかの例において、エンティティ(ノード)の大多数は、ブロックが有効になり、ブロックチェーンネットワークのブロックチェーン(分散台帳)に追加されるように、あらゆるブロックに署名しなければならない。公開ブロックチェーンネットワークの例は、ブロックチェーンと呼ばれる分散台帳を活用する特定のピアツーピアの支払ネットワークを含む。上述のように、用語ブロックチェーンは、それでも、いずれの特定のブロックチェーンネットワークに対する特定の参照もなく、分散台帳を一般に指すために使用される。
一般に、公開ブロックチェーンネットワークは、公開取引をサポートする。公開取引は、公開ブロックチェーンネットワーク内のノードの全てによって共有され、グローバルブロックチェーンに格納される。グローバルブロックチェーンは、全てのノードにわたって複製されるブロックチェーンである。すなわち、全てのノードは、グローバルブロックチェーンに対して完璧な状態のコンセンサスになる。コンセンサス(例えばブロックチェーンへのブロックの追加に対する合意)を実現するために、コンセンサスプロトコルが、公開ブロックチェーンネットワーク内で実行される。コンセンサスプロトコルの例は、プルーフオブワーク(POW: proof-of-work)、プルーフオブステーク(POS: proof-of-stake)、およびプルーフオブオーソリティ(POA: proof-of-authority)を限定することなく含む。POWは、非限定的な例として本明細書でさらに参照される。
一般に、プライベートブロックチェーンネットワークは、読み書き許可を中心に制御する特定のエンティティに提供される。エンティティは、どのノードがブロックチェーンネットワークに参加できるかを制御し、したがって、プライベートブロックチェーンネットワークは、一般に、誰がネットワークに参加することを許されているかに対して、および彼らの参加レベル(例えば一定の取引においてのみ)に対して制約を課す、許可制ネットワーク(permissioned network)と呼ばれる。様々なタイプのアクセス制御メカニズムが使用されることが可能である(例えば、既存の参加者が新しいエンティティの追加を採決し、監督機関が入会を制御することができる)。
一般に、コンソーシアムブロックチェーンネットワークは、参加エンティティ間でプライベートなものである。コンソーシアムブロックチェーンネットワークにおいて、コンセンサス処理は、権限付与された一組のノードによって制御され、1つまたは複数のノードは、個々のエンティティ(例えば、金融機関、保険会社)によって運用される。例えば、10(10)個のエンティティ(例えば、金融機関、保険会社)のコンソーシアムが、コンソーシアムブロックチェーンネットワークを運用することができ、エンティティのそれぞれは、コンソーシアムブロックチェーンネットワーク内で少なくとも1つのノードを運用する。したがって、コンソーシアムブロックチェーンネットワークは、参加エンティティに対するプライベートネットワークと見なされることが可能である。いくつかの例において、各エンティティ(ノード)は、ブロックが有効になり、ブロックチェーンに追加されるように、あらゆるブロックに署名しなければならない。いくつかの例において、エンティティ(ノード)の少なくともサブセット(例えば少なくとも7つのエンティティ)は、ブロックが有効になり、ブロックチェーンに追加されるように、あらゆるブロックに署名しなければならない。
本明細書の実装形態は、コンソーシアムブロックチェーンネットワークを参照しながら本明細書でさらに詳細に説明される。しかし、本明細書の実装形態は、任意の妥当なタイプのブロックチェーンネットワーク内で実現されることが可能であるということが意図される。
本明細書の実装形態は、上記の背景を考慮して本明細書でさらに詳細に説明される。より具体的には、また上記で紹介されたように、本明細書の実装形態は、分散システムにおけるネットワークノードに対して回復処理を行うことを対象とする。
ブロックチェーンは、公開またはプライベートのピアツーピアネットワークに取引を記録する、改ざん耐性のある共有デジタル台帳である。台帳は、ネットワーク内の全てのメンバノードに配布され、ネットワーク内で発生する資産取引の履歴は、ブロック内に永久に記録される。
コンセンサスメカニズムは、分散ブロックチェーンネットワーク内の全てのネットワークノードが、同じ順序で取引を実行し、その後、同じ台帳に書き込むことを保証する。コンセンサスモデルが対処することを目指す1つの問題は、ビザンチン障害を克服することである。ビザンチン障害において、分散ブロックチェーンネットワークのサーバまたはネットワークノードなどの構成要素は、障害検出システムには故障したようにも、機能しているようにも矛盾して見えることがあり、異なる観察者に異なる症状を示す。他のネットワークノードは、どのネットワークノードが最初に故障したのかについてのコンセンサスに最初に達する必要があるので、構成要素が故障していると宣言して、構成要素をネットワークから切り離すのは他のネットワークノードには困難である。
分散システムの背景において、ビザンチンフォールトトレランス(BFT: Byzantine fault tolerance)は、システムの悪意のある構成要素(すなわちブロックチェーンネットワークのネットワークノード)が故障しているか、正しくない情報を他のピアに伝搬させているにもかかわらず、要望通りに機能し、十分なコンセンサスに正しく達するようにする分散コンピュータネットワークの能力である。目的は、ネットワークの正しい機能、およびシステムにおけるまともなノードによって達せられる正しいコンセンサスを、これらの悪意のあるノードが脅かす影響を緩和させることによって壊滅的なシステム障害から守ることである。
しかし、既存のBFTメカニズムは、多くの態様において非効率的であることがわかってきた。例えば、既存のBFTメカニズムは、ビザンチン障害を克服しようとするときの分散ブロックチェーンネットワークに対する実行の複雑性を増加させ、その結果、分散ブロックチェーンネットワークのネットワークノード間の通信に対するレイテンシが増加する。プラクティカルビザンチンフォールトトレランス(PBFT: Practical Byzantine Fault Tolerance)は、既存のBFTコンセンサスメカニズムを改良することを目指す最適化のうちの1つである。PBFTモデルは、独立ノードの故障、および特定の独立ノードによって伝搬される操作されたメッセージがあるという想定を通じて、ビザンチン障害(悪意のあるノード)に耐性のある実用的なビザンチン状態機械の複製を行うことに焦点を当てる。
PBFTモデルにおいて、ノードの全ては順番に並べられ、一方のノードが1次ノード(リーダー)であり、他方がバックアップノードと呼ばれる。システムにおけるノードの全てが互いに通信し、目標は、まともなノードの大多数がシステムの状態の合意に至ることである。ノードは互いに通信して、メッセージが特定のピアノードから来たことを証明しなければならないだけでなく、メッセージが送信中に修正されなかったことを検証する必要もある。
PBFTモデルが機能するためには、脆弱性の所与のウィンドウの中で、ネットワーク内の悪意のあるノードの量が、システムにおける全ノードの1/3以上になることができないということが前提となる。システムにおけるノードが多ければ多いほど、全ノードの1/3に近い数が悪意のあるものである可能性が数学的にますます低くなる。アルゴリズムは、多くても(n-1)/3個のノードが同時に悪意のあるものであるか故障している間、生存性(liveness)と安全性の両方を効果的にもたらし、ここで、nは、全ノードを表す。
(ビューと呼ばれる)PBFTコンセンサスのそれぞれのラウンドは、4つのフェーズを含む。
(1)クライアントは、サービス動作を起動させるためにリーダーノードに要求を送る。
(2)リーダーノードは、バックアップノードに要求をマルチキャストする。
(3)ノードは、要求を実行し、その後、クライアントにリプライを送る。
(4)クライアントは、同じ結果を有する、異なるノードからのf+1個のリプライを待つ(fは、故障している可能性のあるノードの最大数を表す)。
最終結果は、全てのまともなノードが、記録の順序について合意に至り、これらのノードが、合意を受け入れるか、拒絶するというものである。リーダーノードは、全てのビューの中で、ラウンドロビン方式で変更され、リーダーノードが要求をマルチキャストすることなく指定の時間が過ぎた場合は、ビュー変更と呼ばれるプロトコルで置き替えられることさえ可能である。まともなノードの大多数は、リーダーが故障しているかどうかを判定し、このリーダーを、代わりとして一列に並んだ次のリーダーを用いて除去することもできる。
しかし、PBFTコンセンサスメカニズムにはいくつかの限界がある。例えば、PBFTモデルは、ノード間で要求される手に負えない量の通信のため、比較的小さいコンセンサスグループサイズの、このモデルの伝統的な形ではうまく機能することができる。ネットワークノード間で送信される巨大なブロックデータは、ネットワーク負荷問題を引き起こし、ネットワークのボトルネックをもたらす。さらに、PBFTモデルにおける認証メッセージのフォーマットとして方法認証コード(MAC: method authentication code)を使用することは、暗号通貨ネットワークなどの大きいコンセンサスグループにおけるノード間で必要な通信量によって、またMACによって、非効率になる可能性がある。サードパーティへのメッセージの信憑性を証明することが本来的にできなくなる可能性がある。
さらに、PBFTによって使用されるラウンドロビン方法を使用してリーダーノードを変更するときに連続して悪意のあるノードに遭遇することは、まともなリーダーノードを見つける際にレイテンシまたは遅延をもたらすことによってブロックチェーンサービスに影響を及ぼす。例えば、新しいリーダーノードとして第1のネットワークノードを選択するとき、第1のネットワークノードは、悪意のあるノードである可能性があり、したがって新しいリーダーノードとして選択されることは不可能である。ラウンドロビン方法においては、一列に並んだ第2のネットワークノードが、新しいリーダーノードとして選択されることが可能である。しかし、第2のネットワークノードも悪意のあるノードである場合、一列に並んだ別のネットワークノードが、リーダーノードとして適切であるかどうかについて検証されることになる。この処理は、まともな新しいリーダーノードが識別されるまで続く。リーダーノードのこのような頻繁な変更は、ブロックチェーンサービスにおけるかなりのレイテンシをもたらす。
さらに、ブロックチェーンネットワーク内のネットワークノードは、ビザンチン障害またはクラッシュ障害にいつでも遭遇する可能性がある。例えば、ネットワークノードは、悪意のあるサイバー攻撃者によって危険にさらされ、不適当にふるまう可能性がある。危険にさらされるネットワークノードが、即座に回復されない場合、悪意のあるサイバー攻撃者は、検出されることなくネットワークノードの1/3超を壊すことによって、ブロックチェーンネットワークおよびサービスを危険にさらす可能性がある。
既存のBFTコンセンサスメカニズムおよびPBFTコンセンサスメカニズムと関連付けられた上述の問題および懸念に対処するために、本明細書は、分散システムにおけるネットワークノード間のコンセンサスを実現するため、分散システムにおける1次ノードの変更を行うため、および分散システムにおけるネットワークノードに対する回復処理を行うための技法を含む改良されたコンセンサスメカニズムを開示する。説明されるコンセンサスメカニズムは、様々な用途における様々な長所を実現することができる。
例えば、下記で論じられるようなコンセンサス処理は、ブロックチェーンシステムの動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、説明されるコンセンサス処理は、ECコードに従って取引要求をいくつかの消去コード(EC)ブロックにコンバートすること、およびネットワークノードのそれぞれにECブロックのうちの1つを送ることを含む。ECブロックは、元の取引要求よりサイズが小さい。したがって、完全な取引要求の代わりにECブロックをネットワークノードに送ることは、ブロックチェーンネットワークのネットワークノード間で送信されるデータブロックのサイズを低減させ、このことにより、ネットワーク帯域幅を節約し、ネットワーク負荷を低減させる。これは、ネットワークノードのメモリ空間との間で読み書きされるデータのサイズをさらに低減させ、このことにより、ネットワークノードのメモリ空間に対する負担を低減させ、全体的なブロックチェーンシステムの効率性を改善する。
さらに、本明細書は、コンセンサス処理の複数のフェーズに個々の重みを割り当てること、複数のフェーズの個々の重みに基づいて加重和を判断すること、および加重和に基づいて新しい1次ノードを判断することを含むエポック変更処理を説明する。ラウンドロビン方法の代わりの加重和に基づくエポック変更処理は、故障していない新しい1次ノードをタイムリに選ぶことを容易にすることができる。1次ノードは、1次ノードを含むいくつかのネットワークノード間のコンセンサス処理のラウンドを始める権限を有するリーダーノードであることが可能である。ブロックチェーンネットワークの他のネットワークノードは、バックアップノードと呼ばれることが可能である。エポック変更処理は、新しい1次ノードに対して一列に並んだ複数のネットワークノードが故障しているときに、1次ノードの頻繁な変更を引き起こすラウンドロビン方法の問題に対処するのに役立つ可能性がある。ラウンドロビン方式とは異なり、本明細書におけるエポック変更処理は、加重和に応じて新しい1次ノードを選択し、これは、故障していない新しい1次ノードを見つける際のレイテンシまたは遅延を低減させることができる。これは、ブロックチェーンサービスを提供する際の全体的なブロックチェーンシステムの効率性をさらに改善することができる。
さらに、本明細書は、新しい1次ノードとして使用されるネットワークノードによって状態要求メッセージを送ること、および他のネットワークノードから状態リプライメッセージを受け取ることなどの動作を含む回復処理を論じる。これらの動作は、故障しているネットワークノードの回復処理が、他の故障していないネットワークノード間のコンセンサス処理の正常動作に支障を来さないように行われる。これは、回復処理の複雑性を低減させることによって故障しているネットワークノードを回復させるためのコンピューティングリソースおよびネットワークリソースを節約することを容易にする。
図1は、本明細書の実装形態を実行するために使用されることが可能な環境100の例を描写する。いくつかの例において、環境100は、コンソーシアムブロックチェーンネットワーク102にエンティティが参加することを可能にする。環境100は、コンピューティングデバイスまたはシステム106、108、およびネットワーク110を含む。いくつかの例において、ネットワーク110は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、インターネット、またはこれらの組合せを含み、ウェブサイト、ユーザデバイス(例えばコンピューティングデバイス)、およびバックエンドシステムを接続する。いくつかの例において、ネットワーク110は、有線および/またはワイヤレス通信リンクでアクセスされることが可能である。いくつかの例において、ネットワーク110は、コンソーシアムブロックチェーンネットワーク102との通信、およびコンソーシアムブロックチェーンネットワーク102内での通信を可能にする。全体的に、ネットワーク110は、1つまたは複数の通信ネットワークを表す。いくつかのケースにおいて、コンピューティングデバイス106、108は、クラウドコンピューティングシステム(図示せず)のノードであることが可能であり、また各コンピューティングデバイス106、108は、ネットワークによって相互接続され、分散処理システムとして機能する複数のコンピュータを含む別々のクラウドコンピューティングシステムであることが可能である。
描写された例において、コンピューティングシステム106、108は、それぞれ、コンソーシアムブロックチェーンネットワーク102にノードとして参加することを可能にする任意の妥当なコンピューティングシステムを含むことができる。コンピューティングデバイスの例は、サーバ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピューティングデバイス、およびスマートフォンを限定することなく含む。いくつかの例において、コンピューティングシステム106、108は、コンソーシアムブロックチェーンネットワーク102と対話するために1つまたは複数のコンピュータ実行サービスをホストする。例えば、コンピューティングシステム106は、1つまたは複数の他のエンティティ(例えば他のユーザ)との第1のエンティティの取引を管理するために第1のエンティティが使用する取引管理システムなどの、第1のエンティティ(例えばユーザA)のコンピュータ実行サービスをホストすることができる。コンピューティングシステム108は、1つまたは複数の他のエンティティ(例えば他のユーザ)との第2のエンティティの取引を管理するために第2のエンティティが使用する取引管理システムなどの、第2のエンティティ(例えばユーザB)のコンピュータ実行サービスをホストすることができる。図1の例において、コンソーシアムブロックチェーンネットワーク102は、ノードのピアツーピアネットワークとして表され、コンピューティングシステム106、108は、コンソーシアムブロックチェーンネットワーク102に参加する第1のエンティティおよび第2のエンティティのそれぞれのノードを提供する。
図2は、本明細書の実装形態による概念アーキテクチャ200の例を描写する。概念アーキテクチャ200の例は、参加者A、参加者B、および参加者Cにそれぞれ対応する参加者システム202、204、206を含む。各参加者(例えば、ユーザ、企業)は、複数のノード214を含むピアツーピアネットワークとして提供されるブロックチェーンネットワーク212に参加し、複数のノード214のうちの少なくともいくつかは、ブロックチェーン216に情報を不変に記録する。単一のブロックチェーン216が、ブロックチェーンネットワーク212内に概略的に描写されているが、本明細書でさらに詳細に説明されるように、ブロックチェーンネットワーク212の全体にわたってブロックチェーン216の複数のコピーがあり、維持される。
描写された例において、各参加者システム202、204、206は、参加者A、参加者B、および参加者Cのそれぞれによって、またはこれらの代わりに提供され、ブロックチェーンネットワーク内の個々のノード214として機能する。本明細書で使用されるように、ノードは、一般に、ブロックチェーンネットワーク212に接続され、個々の参加者がブロックチェーンネットワークに参加することを可能にする、個々のシステム(例えば、コンピュータ、サーバ)を指す。図2の例において、参加者は、各ノード214に対応する。しかし参加者は、ブロックチェーンネットワーク212内で複数のノード214を動作させることができ、および/または複数の参加者は、ノード214を共有することができるということが意図される。いくつかの例において、参加者システム202、204、206は、プロトコル(例えばハイパーテキスト転送プロトコルセキュア(HTTPS))を使用して、および/またはリモートプロシージャコール(RPC)を使用して、ブロックチェーンネットワーク212と通信するか、ブロックチェーンネットワーク212を介して通信する。
ノード214は、ブロックチェーンネットワーク212内で様々な度合いの参加を行うことができる。例えば、ノード214の中には、(例えばブロックチェーン216にブロックを追加する監視ノード(minder node)として)コンセンサス処理に参加できるものもある一方で、他のノード214は、コンセンサス処理には参加しない。別の例として、ノード214の中には、ブロックチェーン216の完全コピーを格納するものもある一方で、他のノード214は、ブロックチェーン216の一部のコピーしか格納しない。例えば、データアクセス権は、個々の参加者の個々のシステムに個々の参加者が格納するブロックチェーンデータを制限することができる。図2の例において、参加者システム202、204、206は、ブロックチェーン216の個々の完全コピー216'、216''、216'''を格納する。
ブロックチェーン(例えば図2のブロックチェーン216)はブロックのチェーンで構成され、各ブロックがデータを格納する。データの例は、2つ以上の参加者の間の取引を表す取引データを含む。非限定的な例として取引が本明細書で使用されるが、任意の妥当なデータ(例えば、文書、画像、ビデオ、オーディオ)がブロックチェーンに格納されることが可能であるということが意図される。取引の例は、何らかの価値(例えば、資産、製品、サービス、および通貨)の交換を限定することなく含むことができる。取引データは、ブロックチェーン内に不変に格納される。すなわち、取引データが変更されることは不可能である。
ブロックに格納する前に、取引データはハッシュされる。ハッシングは、(文字列データとして提供される)取引データを(同様に文字列データとして提供される)固定長ハッシュ値に変換する処理である。ハッシュ値をアンハッシュして取引データを入手することは不可能である。ハッシングは、取引データのわずかな変更でさえ、完全に異なるハッシュ値を生じることを保証する。さらに、また上述のように、ハッシュ値は固定長のものである。すなわち、取引データのサイズに関係なく、ハッシュ値の長さは固定される。ハッシングは、ハッシュ関数によって取引データを処理し、ハッシュ値を生成することを含む。ハッシュ関数の例は、256ビットハッシュ値を出力するセキュアハッシュアルゴリズム(SHA)-256を限定することなく含む。
複数の取引の取引データはハッシュされ、ブロックに格納される。例えば、2つの取引のハッシュ値が提供され、このハッシュ値自体がハッシュされて別のハッシュをもたらす。この処理は、全ての取引がブロックに格納されるために、単一のハッシュ値が提供されるまで繰り返される。このハッシュ値は、マークルルートハッシュと呼ばれ、ブロックのヘッダに格納される。取引のいずれかの変更は、取引のハッシュ値の変更、および最終的にマークルルートハッシュの変更を生じることになる。
ブロックは、コンセンサスプロトコルを通じてブロックチェーンに追加される。ブロックチェーンネットワーク内の複数のノードは、コンセンサスプロトコルに参加し、ブロックをブロックチェーンに追加することを競う。このようなノードは、マイナー(miner)(または監視ノード)と呼ばれる。上記で紹介されたPOWは、非限定的な例として使用される。
マイナーノードは、コンセンサス処理を実行して、ブロックチェーンに取引を追加する。複数のマイナーノードがコンセンサス処理に参加するが、ただ1つのマイナーノードしか、ブロックチェーンにブロックを書き込むことができない。すなわち、マイナーノードは、コンセンサス処理において、自分のブロックをブロックチェーンに追加することを競う。さらに詳細には、マイナーノードは、(例えば、もしあれば、ブロックに含まれることが可能な取引数に対する所定の限界まで)取引プールから未決の取引を定期的に収集する。取引プールは、ブロックチェーンネットワークの参加者からの取引メッセージを含む。マイナーノードはブロックを構築し、ブロックに取引を追加する。ブロックに取引を追加する前に、マイナーノードは、取引のいずれかがブロックチェーンのブロックに既に含まれているかどうかをチェックする。取引が別のブロックに既に含まれている場合、取引は廃棄される。
マイナーノードはブロックヘッダを生成し、ブロック内の取引の全てをハッシュし、単一のハッシュ値がブロック内の全ての取引に提供されるまでハッシュ値をさらに生成するために2つ1組でハッシュ値を組み合わせる(マークルルートハッシュ)。このハッシュはブロックヘッダに追加される。マイナーは、ブロックチェーン内の最も新しいブロックのハッシュ値(すなわちブロックチェーンに追加される最後のブロック)も判断する。マイナーノードは、ノンス値およびタイムスタンプもブロックヘッダに追加する。マイニング処理において、マイナーノードは、必要なパラメータを満たすハッシュ値を見つけようと試みる。マイナーノードは、必要なパラメータを満たすハッシュ値を見つけるまでノンス値を変更し続ける。
ブロックチェーンネットワーク内の全てのマイナーは、必要なパラメータを満たすハッシュ値を見つけようと試み、このようにして、互いに競う。最終的に、マイナーノードのうちの1つが、必要なパラメータを満たすハッシュ値を見つけ、このことを、ブロックチェーンネットワーク内の他の全てのマイナーノードに知らせる。他のマイナーノードはハッシュ値を検証し、正しいと判断されると、ブロック内の各取引を検証し、ブロックを受け入れ、ブロックチェーンのこれらのコピーにブロックを付加する。このように、ブロックチェーンのグローバル状態は、ブロックチェーンネットワーク内の全てのマイナーノードの全体にわたって一致している。上述の処理は、POWコンセンサスプロトコルである。
図2を参照しながら非限定的な例が提供される。この例において、参加者Aは、ある程度の資金を参加者Bに送ることを望む。参加者Aは、(例えば、Fromフィールド、Toフィールド、および値フィールドを含む)取引メッセージを生成し、ブロックチェーンネットワークに取引メッセージを送り、ブロックチェーンネットワークは、取引メッセージを取引プールに追加する。ブロックチェーンネットワーク内の各マイナーノードはブロックを作り出し、(例えば、もしあれば、ブロックに追加されることが可能な取引数に対する所定の限度まで)取引プールから全ての取引を入手し、ブロックに取引を追加する。このように、参加者Aによって公表された取引は、マイナーノードのブロックに追加される。
いくつかのブロックチェーンネットワークにおいて、取引のプライバシーを維持するために暗号法が実行される。例えば、ブロックチェーンネットワーク内の他のノードが取引の詳細を見分けられないように2つのノードが取引をプライベートに保つことを望む場合、ノードは、取引データを暗号化することができる。暗号化方法の例は、対称暗号化および非対称暗号化を限定することなく含む。対称暗号化は、暗号化(平文から暗号文を生成すること)、および複合(暗号文から平文を生成すること)の両方のために単一キーを使用する暗号化処理を指す。対称暗号化において、複数のノードに対して同じキーが利用できるので、各ノードは、取引データを暗号化すること/復号することができる。
非対称暗号化は、それぞれが秘密鍵および公開鍵を含むキーのペアを使用し、秘密鍵は個々のノードにだけ知られており、公開鍵は、ブロックチェーンネットワーク内のいずれかまたは他の全てのノードに知られている。ノードは、別のノードの公開鍵を使用してデータを暗号化することができ、暗号化されたデータは、他のノードの秘密鍵を使用して復号されることが可能である。例えば、また図2を再度参照すると、参加者Aは、参加者Bの公開鍵を使用してデータを暗号化し、暗号化されたデータを参加者Bに送ることができる。参加者Bは、参加者Bの秘密鍵を使用して暗号化されたデータ(暗号文)を復号し、元のデータ(平文)を抽出することができる。ノードの公開鍵で暗号化されたメッセージは、このノードの秘密鍵を使用して復号されること以外は不可能である。
非対称暗号化は、取引の参加者が、取引の他の参加者ならびに取引の有効性を確認することを可能にするデジタル署名を行うために使用される。例えば、ノードはメッセージにデジタル的に署名することができ、別のノードは、参加者Aのデジタル署名に基づいてノードによってメッセージが送られたことを確認することができる。デジタル署名は、移送中にメッセージが改ざんされていないことを保証するために使用されることも可能である。例えば、また図2を再度参照すると、参加者Aは、メッセージを参加者Bに送ることになる。参加者Aはメッセージのハッシュを生成し、次に、参加者Aの秘密鍵を使用してハッシュを暗号化し、暗号化されたハッシュとしてデジタル署名を行う。参加者Aはデジタル署名をメッセージに付加し、デジタル署名付きのメッセージを参加者Bに送る。参加者Bは、参加者Aの公開鍵を使用してデジタル署名を復号し、ハッシュを抽出する。参加者Bはメッセージをハッシュし、ハッシュを比較する。ハッシュが同じ場合、参加者Bは、メッセージが実際に参加者Aからのものであったこと、および改ざんされていなかったことを確認することができる。
図3は、本明細書の実装形態に従って実行されることが可能な分散システム(例えばブロックチェーンネットワーク102および212)のネットワークノード(例えばノード214)間のコンセンサスを実現するための処理300の例を描写する。具体的には、図3は、本明細書による通常のケースにおけるコンセンサスを実現する方法300の例示的実施形態を提示する図を示す。図3において示されるように、コンセンサス処理300は、下記で論じられるような3つのフェーズ、すなわちステージ310、320、および330を含む。
コンセンサス処理300の第1のフェーズ310において、ブロックチェーンネットワークの1次ノード(またはリーダーノード)は、他のネットワークノード(すなわちバックアップノード)に第1のメッセージを送る。第1のメッセージは、1次ノードがコンセンサス処理を始めていることを示す。例えば、図3において示されるように、1次ノードR0は、ブロックチェーンネットワーク内の他のネットワークノードR1、R2、およびR3にINITIALメッセージを送る。処理300は、例証のためだけに4つのネットワークノードR0、R1、R2、およびR3を含むものとして示されるが、処理300は、任意の適切な数のネットワークノードを含むことができるということに留意されたい。第1のフェーズ、およびINITIALメッセージのフォーマットは、図4〜図6を参照しながら、より詳細に下記で論じられることになる。
コンセンサス処理300の第2のフェーズ320において、バックアップノードのそれぞれは、1次ノードによって送られる第1のメッセージを受け取り、第1のメッセージに応答して第2のメッセージを用意し、他のネットワークノードに第2のメッセージをマルチキャストする。第2のメッセージは、バックアップノードが1次ノードから第1のメッセージを受け取ったこと、および第1のメッセージに応答してリプライを送っていることを示す。例えば、図3において示されるように、バックアップノードR1は、1次ノードR0によって送られているINITIALメッセージを受け取り、第2のメッセージの例としてECHOメッセージで1次ノードR0にリプライする。一方で、バックアップノードR1は、バックアップノードR2およびR3などの他のバックアップノードにもECHOメッセージをマルチキャストする。同様に、バックアップノードR2およびR3は、それそれ、1次ノードR0を含む他のネットワークノードにECHOメッセージをマルチキャストする。
例えば1次ノードまたはバックアップノードなどのネットワークノードが、他のネットワークノードからECHOメッセージを受け取るとき、ネットワークノードは、ECHOメッセージ内の情報を検証することができる。第2のフェーズおよびECHOメッセージのフォーマットは、図4〜図6を参照しながら、より詳細に下記で論じられることになる。
コンセンサス処理300の第3のフェーズ330において、ネットワークノードのそれぞれは、他のネットワークノードに第3のメッセージをマルチキャストする。第3のメッセージは、ネットワークノードが所定の数の第2のメッセージを受け入れたことを示す。いくつかの実装形態において、第3のメッセージは、ネットワークノードが、取引を実行する用意ができたということを示すことができる。いくつかの実装形態において、第3のメッセージは、ネットワークノードにおいて取引が成功裏に再構築されたことを示すことができる。例えば、図3において示されるように、1次ノードR0は、バックアップノードR1、R2、およびR3にACCEPTメッセージをマルチキャストする。同様に、バックアップノードR1、R2、およびR3は、それぞれ、他のネットワークノードにACCEPTメッセージをマルチキャストする。本明細書のいくつかの実装形態において、ACCEPTメッセージをマルチキャストする前に、ネットワークノードは、消去コード(EC)に従ってACCEPTが送られるかどうか、およびECHOメッセージ内の情報が、第2のフェーズにおいて受け取られたものであるかどうかを判断する。第3のフェーズ、ECコード、およびACCEPTメッセージのフォーマットは、図4〜図6を参照しながら、より詳細に下記で論じられることになる。
ネットワークノードが他のネットワークノードから十分なACCEPTメッセージを受け取ると、ネットワークノードは、コンセンサスが実現されたと判断する。例えば、1次ノードR0またはバックアップノードR1、R2、またはR3が、定足数(例えば2f+1、ここでfは、故障しているネットワークノードの数を表す)のACCEPTメッセージを受け取ると、ネットワークノード間でコンセンサスが自動的に実現される。
図4は、本明細書の実装形態に従って実行されることが可能な分散システム(例えばブロックチェーンネットワーク102または212)のネットワークノード(例えばノード214またはノードR0、R1、R2、およびR3)間でコンセンサスを実現するための処理400の例を描写する。いくつかの実装形態において、処理400は、1つまたは複数のコンピューティングデバイスを使用して実行される1つまたは複数のコンピュータ実行可能プログラムを使用して行われることが可能である。表現の明瞭さのために、続く説明は、全体的に、本説明における他の図の背景において方法400を説明する。方法400は、例えば、任意の適切なシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって必要に応じて行われることが可能であるということが理解されよう。いくつかの実装形態において、方法400の様々なステップは、並行に、組み合わせて、ループさせて、または任意の順序で実行されることが可能である。
初めに、処理400は、図1〜図3において示されたようなシステム100〜システム300と共に実行されることが可能である。本明細書のいくつかの実装形態において、ブロックチェーンネットワーク102および/または212は、1次ノード404および1つまたは複数のバックアップノード406を含む。ブロックチェーンネットワーク102および/または212は、ブロックチェーンサービスを提供するためにネットワーク110を介してクライアントノード402などの、コンピューティングシステム106および/または108と通信する。クライアントノード402、1次ノード404、およびバックアップノード406のそれぞれは、本明細書で論じられる処理を行うように構成された専用コンピュータまたは他のデータ処理装置であることが可能である。例えば、クライアントノード402は、ブロックチェーンネットワークと相互作用するクライアント端末またはクライアントデバイスと呼ばれることも可能である。クライアントノード402は、ブロックチェーンネットワークにアクセスするため、およびブロックチェーンネットワークと通信するためにブロックチェーンネットワークと接続状態にある、例えばクライアントアプリケーションまたはクライアントソフトウェア開発キット(SDK)をインストールすることができる。1次ノード404および1つまたは複数のバックアップノード406は、コンセンサスを実現し、ブロックチェーンネットワークに情報を不変に記録するコンセンサスノードまたはネットワークノードと呼ばれることも可能である。
処理400は、408において始まり、ここで、クライアントノード402は、取引要求を生成する。本明細書のいくつかの実装形態において、取引要求は、ブロックチェーンネットワーク102および/または212からのブロックチェーンサービスを要求する要求を含むことができる。
410において、クライアントノード402は、ブロックチェーンネットワーク102および/または212の1次ノード404に取引要求をマルチキャストする。本明細書のいくつかの実装形態において、1次ノード404は、クライアントノード402から取引要求を受け取った後に取引要求を追跡するために、取引要求にシーケンス番号を割り当てる。
412において、1次ノード402は、クライアントノード402から取引要求を受け取った後に、いくつかのECブロックを生成する。本明細書のいくつかの実装形態において、1次ノード404は、取引要求を使用してECコードに従っていくつかのECブロックを生成する。例えば、図5を参照すると、1次ノード404は、取引要求502に対してECコード504を適用し、ECコード504を使用して取引要求502をECメッセージ506に変換する。ECコード504は、ビット消去の前提に基づく前方誤り訂正(FEC)コードである。ECコード504は、元の取引要求502がECメッセージ506の一部または断片から回復されることが可能になるように、元の取引要求502をより長いECメッセージ506に変換する。
本明細書のいくつかの実装形態において、ECコード504は、Tornadoコードまたは低密度パリティ検査符号などの、ほぼ最適な消去コードである。本明細書の代替実装形態において、ECコード504は、ファウンテンコード、オンラインコード、Luby変換(LT)コード、またはラプターコードなどの、ほぼ最適なファウンテンコードである。本明細書の代替実装形態において、ECコード504は、パリティコード、Parchiveコード、リードソロモンコード、または再生成コードなどの、最適な消去コードである。本明細書のいくつかの実装形態において、ECコード504は、任意の適切なタイプの消去コードであることが可能である。
取引要求502をECメッセージ506に変換した後、1次ノード404は、ECメッセージ506を使用して、いくつかのECブロック508を生成する。例えば、図5において示されるように、1次ノード404は、ECメッセージ506を分割することによって、ECブロックA、ECブロックB、ECブロックC、およびECブロックDという4つのECブロック508を生成する。ECブロック508は、例証のために4つのブロックを含むものとして図5において示されているが、ECブロック508は、任意の適切な数のECブロック508を含むものとして生成されることが可能であるということに留意されたい。ECブロック508は、INITIALメッセージの中で個々のバックアップノード406に送られることになる。
本明細書のいくつかの実装形態において、ECブロック508は同じサイズを有する。しかし、代替実装形態において、ECブロック508は、互いに異なるサイズを有することができる。
本明細書のいくつかの実装形態において、1次ノード404は、ECブロック508を使用してハッシュ木500(例えばマークル木)を生成する。ハッシュ木500は、データブロックのハッシュでラベル付けされたいくつかの葉ノード、および非葉ノードの子ノードのラベルの暗号学的ハッシュでラベル付けされたいくつかの非葉ノードを含む。例えば、図5に示されたように、ハッシュ木500は、4つの葉ノード510の個々のECブロック508の暗号学的ハッシュとして生成されたハッシュA、ハッシュB、ハッシュC、およびハッシュDという4つの葉ノード510、4つの非葉ノード512の個々の子ノード510の連鎖のハッシュとして生成された4つの非葉ノード512、および非葉ノード514の子ノード512のハッシュとして生成され、ハッシュ木500のルートハッシュである非葉ノード514を含むものとして構成される。
ハッシュ木500は、大きいデータ構造の内容の効率的かつ安全な検証を可能にする。ハッシュ木500は、コンピュータ内で、またコンピュータ間で格納され、取り扱われ、移送される任意の種類のデータを検証するために使用されることが可能である。ハッシュ木500は、P2Pネットワーク内の他のピアから受け取られたデータブロックが無傷であり変更されずに受け取られることを保証すること、および他のピアが偽造ブロックを送っていないことをチェックすることにさえ役立つ可能性がある。ハッシュ木500を使用するデータブロックの検証が、コンセンサス処理400の以下のステップを参照しながら、より詳細に下記で論じられることになる。
図4を再度参照すると、1次ノード404は、ECブロック508およびハッシュ木500を生成した後、第1のメッセージ(例えばINITIALメッセージ)を生成する。第1のメッセージは、1次ノードがコンセンサス処理を始めていることを示す。いくつかの実装形態において、第1のメッセージの例としてのINITIALメッセージは、ECブロック508およびハッシュ木500内の情報を使用して生成される。本明細書のいくつかの実装形態において、図6を参照すると、INITIALメッセージは、<epoch, tx_root_hash, ec_block_hash, ec_block, seq, j>というフォーマットを有し、ここで、「epoch」は、メッセージが送られているコンセンサスのラウンドを表し、「tx_root_hash」は、ハッシュ木500内のルートハッシュ514を表し、「ec_block_hash」は、ハッシュ木500内のハッシュ510および/または512を表し、「ec_block」は、ハッシュ木500内のECブロック508を表し、「seq」は、取引要求502と関連付けられたシーケンス番号を表し、「j」は、INITIALメッセージを生成して送るネットワークノードを表す。いくつかの実装形態において、INITIALメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
図4を再度参照すると、416において、コンセンサス処理の第1のフェーズにおいて、1次ノード404は、他のネットワークノード(例えばバックアップノード406)にINITIALメッセージをマルチキャストする。いくつかの実装形態において、バックアップノード406に送られるINITIALメッセージは、<epoch, tx_root_hash, ec_block_hash, ec_block, seq, j>というフォーマットを有する。例えば、1次ノード404は、第1のINITIALメッセージ<epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 0>を第1のバックアップノード406に送ること、および第2のINITIALメッセージ<epoch 1, Hash ABCD, {Hash A, Hash C, Hash D}, EC block B, 1, 0>を第2のバックアップノード406に送ること、などを行うことができる。「ec_block」などのINITIALメッセージ内の情報は、ハッシュ木500を再構築するために「ec_block_hash」と共に使用されることが可能であるということに留意されたい。例えば、第1のINITIALメッセージ<epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 0>において、「ECブロックA」というECブロック508は、「Hash A」という暗号学的ハッシュ510を生成するためにハッシュされることが可能であり、「Hash A」は、ハッシュ木500を再構築するために「{Hash B, Hash C, Hash D}」という他のハッシュ510と共にさらに使用される。再構築されたハッシュ木500は、コンセンサス処理の以下のステップを参照しながら、より詳細に下記で論じられるような、ECHOメッセージを検証するために使用されることになる。
418において、バックアップノード406のそれぞれは、1次ノード404からINITIALメッセージを受け取った後、コンセンサス処理の第2のフェーズにおいて第2のメッセージ(例えばECHOメッセージ)を生成する。第2のメッセージは、バックアップノードが1次ノードから第1のメッセージを受け取ったということを示す。第2のメッセージは、第1のメッセージに応答してリプライとして送られる。本明細書のいくつかの実装形態において、ECHOメッセージは、INITIALメッセージまたはINITIALメッセージの一部、およびINITIALメッセージと関連付けられたバックアップノード406の署名を含むものとしてバックアップノード406によって生成される。例えば、バックアップノード406は、秘密鍵を使用して、INITIALメッセージまたはINITIALメッセージのダイジェストに署名することによって署名を生成することができる。秘密鍵署名は、秘密鍵署名を含むECHOメッセージを認証するために、秘密鍵とペアになる公開鍵を使用して、他のネットワークノードによって使用されることが可能である。
本明細書のいくつかの実装形態において、図6を参照すると、ECHOメッセージは、<epoch, tx_root_hash, ec_block_hash, ec_block, seq, sign_proof, j>というフォーマットを有し、ここで、「epoch」は、メッセージが送られているコンセンサスのラウンドを表し、「tx_root_hash」は、ハッシュ木500内のルートハッシュ514を表し、「ec_block_hash」は、ハッシュ木500内のハッシュ510および/または512を表し、「ec_block」は、個々のバックアップノード406によって受け取られるハッシュ木500内のECブロック508を表し、「seq」は、取引要求502と関連付けられたシーケンス番号を表し、「sign_proof」は、INITIALメッセージと関連付けられたバックアップノード406の署名を表し、「j」は、ECHOメッセージを生成して送るネットワークノードを表す。いくつかの実装形態において、ECHOメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
図4を再度参照すると、420において、バックアップノード406は、1次ノード404にECHOメッセージを送る。421において、バックアップノード406のそれぞれは、他のバックアップノード406にECHOメッセージを送る。423において、バックアップノード406のそれぞれは、他のバックアップノード406からECHOメッセージを受け取ることができる。
422において、1次ノード404は、バックアップノード406によって送られたECHOメッセージを検証する。本明細書のいくつかの実装形態において、1次ノード404は、ハッシュ木500に従ってECHOメッセージが有効であるかどうかを検証する。例えば、1次ノード404は、第1のECHOメッセージ<epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 1>を第1のバックアップノード406から受け取ることができる。1次ノード404は、「ECブロックA」というECブロック508をメッセージから取得し、「ECブロックA」をハッシュして、「ハッシュA」という暗号学的ハッシュ510を生成する。1次ノード404は、メッセージ内の「{Hash B, Hash C, Hash D}」という他のハッシュ510と共に、「ハッシュA」という生成されたハッシュ510をさらに使用して、ハッシュ木500を再構築する。次に、1次ノード404は、再構築されたハッシュ木500のルートハッシュ514を判断し、このルートハッシュ514を、「Hash ABCD」などのECHOメッセージ内のルートハッシュ514と比較する。2つのルートハッシュ514がマッチする場合、1次ノード404は、ECHOメッセージが有効であると判断する。1次ノード404は、有効なECHOメッセージを格納すること、および無効であると判断されたECHOメッセージを廃棄することができる。
424において、1次ノード404は、有効なECHOメッセージの数が所定の閾値を超過するかどうかを判断する。本明細書のいくつかの実装形態において、1次ノード404は、有効なECHOメッセージの数が、定足数n-fまたは2f+1に達しているかどうかを判断し、ここで、nは、ネットワークノードの総数であり、fは、ネットワークが許容できる故障ノードの最大数である。
426において、1次ノード404は、有効なECHOメッセージの数が定足数に達したとの判断に応答して取引要求502を再構築する。本明細書のいくつかの実装形態において、1次ノード404は、ECコードに従って有効なECHOメッセージの少なくともサブセットに基づいて取引要求502を再構築する。例えば、1次ノード404は、有効なECHOメッセージの定足数(例えばn-fまたは2f+1)の範囲内のn-2f個またはf+1個のECブロック508を取得し、取得したECブロック508を使用してECコード504に従って取引要求502を再構築することができる。
428において、コンセンサス処理の第3のフェーズにおいて、1次ノード404は、取引要求502が成功裏に再構築されたとの判断に応答して、第3のメッセージ(例えばACCEPTメッセージ)を生成する。第3のメッセージは、ネットワークノードが所定の数の第2のメッセージを受け入れたことを示す。いくつかの実装形態において、第3のメッセージは、ネットワークノードが取引を実行する用意ができたということを示すことができる。いくつかの実装形態において、第3のメッセージは、ネットワークノードにおいて取引が成功裏に再構築されたことを示すことができる。例えば、ACCEPTメッセージは、取引要求502が成功裏に再構築されたことを他のネットワークノードに示すために使用されることが可能である。1次ノード404が、取引要求502を再構築するのに失敗した場合、1次ノード404は、ACCEPTメッセージを生成することができない。
本明細書のいくつかの実装形態において、図6を参照すると、ACCEPTメッセージは、<epoch, tx_root_hash, seq, sign_proofs, j>というフォーマットを有し、ここで、「epoch」は、メッセージが送られているコンセンサスのラウンドを表し、「tx_root_hash」は、ハッシュ木500内のルートハッシュ514を表し、「seq」は、取引要求502と関連付けられたシーケンス番号を表し、「sign_proofs」は、有効なECHOメッセージ内の署名のセットを表し、「j」は、ACCEPTメッセージを生成して送るネットワークノードを表す。いくつかの実装形態において、ACCEPTメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することが可能である。
図4を再度参照すると、430において、1次ノード404は、バックアップノード406にACCEPTメッセージを送る。
1次ノード404と同様に、バックアップノード406のそれぞれは、例えば1次ノード404としてステップ422〜ステップ428と同様のステップを行うことによって、取引要求を再構築することができる。432において、バックアップノード406のそれぞれは、バックアップノード406によって取引要求502が成功裏に再構築したとの判断に応答して、ACCEPTメッセージを生成する。いくつかの実装形態において、1次ノード404およびバックアップノード406は、例えば図3において示されるように、ステップ422〜ステップ428を並列に行うことができる。
434において、バックアップノード406は、1次ノード404にACCEPTメッセージを送る。一方で、バックアップノード406のそれぞれは、他のバックアップノード406にACCEPTメッセージを送ることができる。
436において、1次ノード404は、ACCEPTメッセージの数が所定の閾値を超過しているとの判断に応答して、取引要求502を実行する。本明細書のいくつかの実装形態において、1次ノード404は、受け取ったACCEPTメッセージが同一であるかどうか、および同一であるACCEPTメッセージの数が定足数(例えば2f+1)に達しているかどうかを判断する。同一のACCEPTメッセージの数が定足数に達していると、1次ノード404は、ネットワークノード全体の間でコンセンサスが実現されたと判断し、次に、取引要求502をローカルに実行する。本明細書のいくつかの実装形態において、同一であるACCEPTメッセージの数が定足数に達していないと1次ノード404が判断すると、1次ノード404は、ネットワークノード全体の間でコンセンサスが実現されなかったと判断し、その後、取引要求502を実行するのを控える。
本明細書のいくつかの実装形態において、バックアップノード406のそれぞれは、取引要求502を実行する前に、436において上述のような、1次ノード404によって行われる同じ動作を行うことができる。バックアップノード406が受け取るACCEPTメッセージが所定の閾値を超過しているとバックアップノード406が判断すると、バックアップノード406は、ネットワークノード間でコンセンサスが実現されたと判断し、取引要求502をローカルに実行する。本明細書のいくつかの実装形態において、同一であるACCEPTメッセージの数が定足数に達していないとバックアップノード406が判断すると、バックアップノード406は、ネットワークノード全体の間でコンセンサスが実現されなかったと判断し、その後、取引要求502を実行するのを控える。
438において、1次ノード404は、取引要求502を実行した後、クライアントノード402に取引結果を送る。取引要求502をローカルに成功裏に実行したバックアップノード406は、取引要求502の個々の取引結果をクライアントノード402に送ることもできる。
上述のようなコンセンサス処理は、ブロックチェーンシステム全体の動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、本明細書におけるコンセンサス処理は、取引要求を使用してECコードに従っていくつかのECブロックを生成し、ネットワークノードのそれぞれにECブロックのうちの1つを送ることを含む。ECブロックは、元の取引要求よりサイズが小さい。したがって、取引要求の代わりにECブロックをネットワークノードに送ることは、ブロックチェーンネットワークのネットワークノード間で送信されるデータブロックのサイズを低減させ、このことにより、ネットワーク帯域幅を節約し、ネットワーク負荷を低減させる。これは、ネットワークノードのメモリ空間との間で読み書きされるデータのサイズをさらに低減させ、このことにより、ネットワークノードのメモリ空間に対する負担を低減させ、全体的なブロックチェーンシステムの効率性を改善する。
コンセンサス処理の間、バックアップノードは、1次ノードからの要求を待っている。しかし、1次ノードは、ビザンチン障害またはクラッシュ障害に遭遇する可能性があり、その結果、1次ノードは、所定の時間ウィンドウの中で要求をブロードキャストすることができない。1次ノードが要求をマルチキャストすることなく指定の時間が過ぎると、実行すべき要求をバックアップノードが無期限に待つのを防ぐために新しい1次ノードが選ばれる必要がある可能性がある。
図7は、本明細書の実装形態に従って実行されることが可能な分散システム(例えばブロックチェーンネットワーク102および212)の1次ノードの変更(例えばノード214または404)を行うための処理700の例を描写する。具体的には、図7は、本明細書による、1次ノードの変更を行う方法700の例示的実施形態を提示する図を示す。いくつかの実装形態において、1次ノードは、1次ノードがリーダーであるコンセンサス処理を含むエポックと関連付けられる。1次ノードの変更は、エポックの変更をもたらすことが可能である。
いくつかの実装形態において、現在のエポックの1次ノードが変更される必要があるとの判断に応答して、ブロックチェーンネットワークのバックアップノードは、他のネットワークノードに第1のメッセージを送る。第1のメッセージは、新しいエポックにおける新しい1次ノードであることをバックアップノードが望んでいることを示す。例えば、図7において示されたように、バックアップノードR0は、現在の1次ノードが故障しており、エポック変更が行われる必要があるとのバックアップノードR0の判断に応答して、ブロックチェーンネットワーク内の他のネットワークノードR1、R2、およびR3にEPOCH_CHANGEメッセージを送る。EPOCH_CHANGEメッセージは、バックアップノードR0が新しい1次ノードとして使用されることを示す第1のメッセージの1つの例である。エポック変更は、現在の1次ノードによる現在のエポックから、新しい1次ノードによる新しいエポックへの変更を引き起こすことができる。処理700は、例証のためだけに4つのネットワークノードによって実行されるものとして示されているということに留意されたい。処理700は、任意の適切な数のネットワークノードによって実行されることが可能である。
次に、ネットワークノードのそれぞれは、バックアップノードによって送られた第1のメッセージを受け取り、第1のメッセージに応答して第2のメッセージを用意し、他のネットワークノードに第2のメッセージをマルチキャストする。例えば、図7において示されたように、ネットワークノードR1は、バックアップノードR0によって送られたEPOCH_CHANGEメッセージを受け取り、バックアップノードR0が新しい1次ノードになることができるという承認を示すNEW_EPOCHメッセージと共にバックアップノードR0にリプライする。一方で、ネットワークノードR1は、ネットワークノードR2およびR3などの他のネットワークノードにもNEW_EPOCHメッセージをマルチキャストする。同様に、ネットワークノードR2およびR3はそれぞれ、他のネットワークノードにNEW_EPOCHメッセージをマルチキャストする。
上述のようなエポック変更処理、EPOCH_CHANGEメッセージのフォーマット、およびNEW_EPOCHメッセージのフォーマットは、図8〜図9を参照しながら、より詳細に下記で論じられることになる。
図8は、本明細書の実装形態に従って実行されることが可能な分散システム(例えばブロックチェーンネットワーク102または212)における1次ノードの変更を行うための処理800の例を描写する。いくつかの実装形態において、処理800の例は、1つまたは複数のコンピューティングデバイスを使用して実行される1つまたは複数のコンピュータ実行可能プログラムを使用して行われることが可能である。表現の明瞭さのために、続く説明は、全体的に、本説明における他の図の背景において方法800を説明する。方法800は、例えば、任意の適切なシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって必要に応じて行われることが可能であるということが理解されよう。いくつかの実装形態において、方法800の様々なステップは、並行に、組み合わせて、ループさせて、または任意の順序で実行されることが可能である。
処理800は、806において始まり、ここで、バックアップノード802は、エポック変更が行われる必要があると判断する。本明細書で論じられるエポック変更は、現在の1次ノードによる現在のエポックから、新しい1次ノードによる新しいエポックへの変更を引き起こす。エポックの例は、図3〜図6を参照しながら上述されたように、1次ノードを使用して、いくつかのネットワークノード間のコンセンサスを実現するためのコンセンサス処理(例えばコンセンサス処理300または400)を含むことができる。
本明細書のいくつかの実装形態において、バックアップノード802は、現在の1次ノードからの要求を受け取ることなく指定の時間が過ぎた後、現在の1次ノードからの要求をバックアップノード802がまだ待っているとの判断に応答して、エポック変更が行われる必要があると判断する。例えば、現在の1次ノードは、ビザンチン障害またはクラッシュ障害に遭遇する可能性があり、その結果、現在の1次ノードは、所定の時間ウィンドウの中で要求をマルチキャストすることができない。したがって、実行すべき要求をバックアップノードが無期限に待つのを防ぐタイムアウトによってエポック変更が誘発される。本明細書で論じられるエポック変更処理は、生存性をもたらし、1次ノードが故障したときにシステムが進行するのを可能にすることによって、ネットワークレイテンシを低減させる。
808において、バックアップノード802は、現在のエポックにおけるコンセンサス処理のフェーズのそれぞれと関連付けられたバックアップノード802の個々の重みを判断する。いくつかの実装形態において、コンセンサス処理は、図3〜図6を参照しながら上述されたような3つのフェーズを含む。重みは、新しいエポックにおいて新しい1次ノードになるためのバックアップノード802の資格の測定基準である。
本明細書のいくつかの実装形態において、バックアップノード802は、現在のエポックにおけるコンセンサス処理の第1のフェーズに対するバックアップノード802の重みが第1の値であると判断する。例えば、バックアップノード802は、コンセンサス処理の第1のフェーズ(例えばコンセンサス処理300の第1のフェーズ310)にバックアップノード802が入った場合、初期の重み10%を割り当てられることが可能である。本明細書の代替実装形態において、バックアップノード802は、現在のコンセンサス処理の第1のフェーズに対するバックアップノード802に任意の適切な重み値を割り当てることができる。
本明細書のいくつかの実装形態において、バックアップノード802は、定足数検証処理に基づいて、現在のエポックにおけるコンセンサス処理の第2のフェーズ(例えばコンセンサス処理300の第2のフェーズ320)に対するバックアップノード802の重みを判断する。定足数検証処理は、コンセンサス処理の第2のフェーズにおいて所定の数(例えば2f+1)のECHOメッセージをバックアップノード802が他のネットワークノードから受け取ったかどうかを判断することによって行われる。
本明細書のいくつかの実装形態において、バックアップノード802が定足数検証に失敗すると(例えば、所定の閾値より少ないいくつかのECHOメッセージをバックアップノード802が受け取る)、バックアップノード802は、コンセンサス処理の第2のフェーズに対するバックアップノード802の重みが第1の値であると判断することができる。バックアップノード802が定足数検証にパスすると(例えば、所定の閾値以上のいくつかのECHOメッセージをバックアップノード802が受け取る)、バックアップノード802は、コンセンサス処理の第2のフェーズに対するバックアップノード802の重みが第2の値であると判断することができる。本明細書のいくつかの実装形態において、第2の値は、第1の値より大きいものと判断される。例えば、バックアップノード802が定足数検証に失敗すると、バックアップノード802は、コンセンサス処理の第2のフェーズに対して、重み値ゼロを割り当てられることが可能である。バックアップノード802が定足数検証にパスすると、バックアップノード802は、コンセンサス処理の第2のフェーズに対するバックアップノード802に対して重み値45%を割り当てられることが可能である。しかし、本明細書の代替実装形態において、バックアップノード802は、現在のエポックにおけるコンセンサス処理の第2のフェーズに対するバックアップノード802に任意の適切な値を割り当てることができる。
本明細書のいくつかの実装形態において、定足数検証は、コンセンサス処理の第2のフェーズ中にバックアップノード802が他のネットワークノードから受け取ったECHOメッセージが有効であるかどうかを検証することをさらに含む。例えば、バックアップノード802は、ECHOメッセージが有効であるかどうかを判断するための公開鍵を使用して、ECHOメッセージ内の秘密鍵署名を認証することができる。
第2のフェーズに対して重みを判断することと同様に、いくつかの実装形態において、バックアップノード802は、定足数検証処理に基づいて、現在のエポックにおけるコンセンサス処理の第3のフェーズ(例えばコンセンサス処理300の第3のフェーズ330)に対するバックアップノード802の重みを判断する。定足数検証処理は、現在のエポックにおけるコンセンサス処理の第3のフェーズにおいて、所定の数(例えば2f+1)の受け入れメッセージをバックアップノード802が他のネットワークノードから受け取ったかどうかを判断することによって行われる。他のネットワークノードからの受け入れメッセージのそれぞれは、他のネットワークノードのそれぞれが所定の数のECHOメッセージを受け入れたということを示す。受け入れメッセージは、例えば、コンセンサス処理300の第3のフェーズ330を参照しながら上述されたACCEPTメッセージであることが可能である。
本明細書のいくつかの実装形態において、バックアップノード802が定足数検証に失敗すると(例えば、所定の閾値より少ないいくつかのACCEPTメッセージをバックアップノード802が受け取る)、バックアップノード802は、コンセンサス処理の第3のフェーズに対するバックアップノード802の重みが第1の値であると判断することができる。バックアップノード802が定足数検証にパスすると(例えば、所定の閾値以上のいくつかのACCEPTメッセージをバックアップノード802が受け取る)、バックアップノード802は、コンセンサス処理の第3のフェーズに対するバックアップノード802の重みが第2の値であると判断することができる。いくつかの実装形態において、第2の値は、第1の値より大きいものと判断される。例えば、バックアップノード802が定足数検証に失敗すると、バックアップノード802は、コンセンサス処理の第2のフェーズに対するバックアップノード802に対して重み値ゼロを割り当てられることが可能である。バックアップノード802が定足数検証にパスすると、バックアップノード802は、コンセンサス処理の第2のフェーズに対するバックアップノード802に対する重み値45%を割り当てられることが可能である。しかし、本明細書の代替実装形態において、バックアップノード802は、現在のエポックにおけるコンセンサス処理の第3のフェーズに対するバックアップノード802に任意の適切な値を割り当てることができる。
810において、現在のエポックにおけるコンセンサス処理のフェーズに対してバックアップノード802の個々の重みを判断した後、バックアップノード802は、個々の重みに基づいてコンセンサス処理に対するバックアップノード802の加重和を判断する。本明細書のいくつかの実装形態において、加重和は、現在のエポックにおけるコンセンサス処理のフェーズのそれぞれと関連付けられたバックアップノードの個々の合計の合計である。例えば、第1のフェーズに対するバックアップノード802の第1の重み値が10%であり、第2のフェーズに対するバックアップノード802の第2の重み値が45%であり、第3のフェーズに対するバックアップノード802の第3の重み値が45%であるとバックアップノード802が判断した場合、バックアップノード802は加重和を100%であると判断する。別の例として、第1のフェーズに対するバックアップノード802の第1の重み値が10%であり、第2のフェーズに対するバックアップノード802の第2の重み値が45%であり、第3のフェーズに対するバックアップノード802の第3の重み値が0であるとバックアップノード802が判断すると、バックアップノード802は加重和が55%であると判断する。
812において、バックアップノード802は、810において判断された加重和が所定の閾値に達しているか超過しているとバックアップノード802が判断すると、他のネットワークノード804にEPOCH_CHANGEメッセージを送る。例えば、バックアップノード802は、810において判断されたような加重和が100%に達すると、他のネットワークノード804にEPOCH_CHANGEメッセージを送ることができる。EPOCH_CHANGEメッセージは、現在の1次ノードによる現在のエポックから、バックアップノードが新しい1次ノードになる新しいエポックへの変更のための要求を示す。
本明細書のいくつかの実装形態において、図9を参照すると、EPOCH_CHANGEメッセージは、<weight, epoch+1, ECHO{}, ACCEPT{}, j>というフォーマットを有し、ここで、「weight」は、コンセンサス処理に対する、810において以前に判断されたような、バックアップノード802の加重和を表し、「epoch+1」は、新しい1次ノードと関連付けられた新しいコンセンサスのラウンド(すなわち新しいエポック)を表し、「ECHO{}」は、コンセンサス処理の第2のフェーズ中にバックアップノード802が受け取ったECHOメッセージのセットを表し、「ACCEPT{}」は、コンセンサス処理の第3のフェーズ中にバックアップノード802が受け取ったACCEPTメッセージのセットを表し、「j」は、EPOCH_CHANGEメッセージを生成して送るネットワークノード(例えばバックアップノード802)を表す。いくつかの実装形態において、EPOCH_CHANGEメッセージは、例えば、追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
図8を再度参照すると、814において、バックアップノード802以外のネットワークノード804は、バックアップノード802によって送られたEPOCH_CHANGEメッセージを検証する。いくつかの実装形態において、ネットワークノード804のそれぞれは、EPOCH_CHANGEメッセージ内の加重和が有効であるかどうかを検証することによって、EPOCH_CHANGEメッセージが有効であるかどうかを検証する。いくつかの実装形態において、EPOCH_CHANGEメッセージ内の加重和が有効であるかどうかを検証することは、EPOCH_CHANGEメッセージに含まれるECHOメッセージ内の署名のセットが有効であるかどうかを検証することを含む。例えば、ネットワークノード804のそれぞれは、公開鍵を使用してEPOCH_CHANGEメッセージを含んだECHOメッセージ内の秘密鍵署名のセットを認証することができる。
816において、ネットワークノード804のそれぞれは、バックアップノード802によって送られたEPOCH_CHANGEメッセージが有効であることの検証に応答して、バックアップノード802にNEW_EPOCHメッセージを送る。NEW_EPOCHメッセージは、新しい1次ノードにバックアップノードがなることについての承認を示す。例えば、ネットワークノード804によって送られたNEW_EPOCHメッセージは、バックアップノード802が新しいエポックにおける新しい1次ノードになることをネットワークノード804が承認するという指示を含む。一方で、ネットワークノード804のそれぞれは、他のネットワークノード804にもNEW_EPOCHメッセージを送る。
図9を参照すると、NEW_EPOCHメッセージは、<epoch+1, i, j, seq, ec_digest>というフォーマットを有するものとして生成しており、ここで、「epoch+1」は、新しい1次ノードと関連付けられた新しいコンセンサスのラウンド(すなわち新しいエポック)を表し、「i」は、新しいエポックにおける新しい1次ノードを表し、「j」は、NEW_EPOCHメッセージを送るネットワークノード804を表し、「ec_digest」は、EPOCH_CHANGEメッセージのダイジェストを表す。いくつかの実装形態において、EPOCH_CHANGEメッセージのダイジェストは、EPOCH_CHANGEメッセージのハッシュ値を含む。いくつかの実装形態において、NEW_EPOCHメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
図8を再度参照すると、818において、バックアップノード802は、ネットワークノード804によって送られたNEW_EPOCHメッセージが有効であるかどうかを検証する。いくつかの実装形態において、バックアップノード802は、NEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することによってNEW_EPOCHメッセージを検証する。ダイジェストはEPOCH_CHANGEメッセージの情報を含むので、ダイジェストは、EPOCH_CHANGEメッセージ内の署名も含む。バックアップノード802は、EPOCH_CHANGEメッセージ内の署名のセットが有効であるかどうかを検証することによってEPOCH_CHANGEメッセージのダイジェストを検証することができる。
820において、バックアップノード802は、818において判断されるような有効なNEW_EPOCHメッセージの数が所定の閾値を超過するかどうかを判断する。いくつかの実装形態において、所定の閾値は定足数(例えば2f+1)である。
822において、バックアップノード802は、判断されたような有効なNEW_EPOCHメッセージの数が所定の閾値を超過したとの判断に応答して、バックアップノード802が新しいエポックにおける新しい1次ノードであると判断する。ネットワークノード804のそれぞれは、バックアップノード802が行うのと同じステップ818〜ステップ822を行い、ネットワークノード804およびバックアップノード802は、ステップ818〜ステップ822を並列に行うことができるということに留意されたい。例えば、ネットワークノード804のそれぞれは、他のネットワークノード804から送られたNEW_EPOCHメッセージのセットを検証し、有効なNEW_EPOCHメッセージの数が所定の閾値を超過しているかどうかを判断し、新しい1次ノードを判断することができる。
上述のようなエポック変更処理(例えば処理700または800)は、ブロックチェーンシステム全体の動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、本明細書におけるエポック変更処理は、コンセンサス処理の3つのフェーズに個々の重みを割り当てること、3つのフェーズの個々の重みに基づいて加重和を判断すること、および加重和に基づいて新しい1次ノードを判断することを含む。ラウンドロビン方法の代わりの加重和に基づくエポック変更処理は、故障していない新しい1次ノードをタイムリに選ぶことを容易にすることができる。ラウンドロビン方法は、新しい1次ノードに対して一列に並んだ複数のネットワークノードが故障しているときに、1次ノードの頻繁な変更を引き起こす可能性がある。これは、故障していない1次ノードを見つける際にレイテンシまたは遅延をもたらすことによってブロックチェーンサービスに著しく影響を及ぼす。ラウンドロビン方法とは異なり、本明細書におけるエポック変更処理は、加重和に応じて新しい1次ノードを選択し、これは、故障していない新しい1次ノードを見つける際の時間を低減させることができる。これは、ブロックチェーンサービスを提供する際の全体的なブロックチェーンシステムの効率性をさらに改善することができる。
ブロックチェーンネットワークの動作中、いくつかのネットワークノードの実行速度は、ネットワークジタリング(network jittering)、突然の電源障害、ディスク障害、および同様のもののために、ほとんどのネットワークノードの実行速度より遅れることがある。このシナリオにおいて、システムにおけるネットワークノードの1/3超が、故障する可能性がある。BFTは、ネットワークノードの1/3未満がシステムの存続時間中に故障する場合の安全性および生存性をもたらす。しかし、これらの保証は、上述のようなシナリオにおいて上限を超過する可能性があるので、長寿命のシステムには不十分である。したがって、ネットワークノードの存続期間にわたってf個超の障害をシステムが許容できるように、故障しているネットワークノードを再度正しく動作させ、その後のコンセンサス処理に参加し続けるという回復処理が望ましい。さらに、説明される回復処理は、コンセンサス処理(例えばコンセンサス処理300または400)をまだ行っている1つまたは複数のネットワークノードを回復させることができ、ネットワークノード全体の間でコンセンサスが達せられるまで待つ必要はない。したがって、説明される回復処理は、システムのレイテンシをさらに低減させ、ブロックチェーンネットワークの効率性を改善することができる。
図10は、本明細書の実装形態に従って実行されることが可能な分散システム(例えばブロックチェーンネットワーク102および212)のネットワークノード(例えばノード214または404)の回復処理を行うための処理1000の例を描写する。具体的には、図10は、本明細書によるネットワークノードの回復処理を行う方法1000の例示的実施形態を提示する図を示す。図10において示されたように、処理1000は、いくつかのフェーズおよびステージを含む。
第1のフェーズ1010において、対象シーケンス番号R0の対象取引を回復させることを望むネットワークノード(例えばネットワークノードR0)は、ネットワークノードが回復されることになることを示す状態要求メッセージ(例えばQUERY_STATEメッセージ)を他のネットワークノードにマルチキャストする。状態要求メッセージは、ネットワークノードR0が回復させることを望む対象シーケンス番号を含むことができる。第2のフェーズ1020において、他のネットワークノードは、状態要求メッセージを受け取り、状態リプライメッセージ(例えばREPLY_STATEメッセージ)をネットワークノードR0に送る。第3のフェーズ1030において、ネットワークノードR0は、他のネットワークノードのそれぞれからのECHOメッセージを要求する要求メッセージ(例えばFETCH_ECHOメッセージ)を他のネットワークノードに送る。ECHOメッセージは、図3〜図6を参照しながら上記で論じられたような、コンセンサス処理300の第2のフェーズ320において個々の他のネットワークノードによって送られた同じECHOメッセージであることが可能である。第4のフェーズ1040において、他のネットワークノードのそれぞれは、FETCH_ECHOメッセージに応答して、ネットワークノードR0にECHOメッセージを送る。第5のフェーズ1050において、ネットワークノードR0はECHOメッセージを検証し、例えば図4を参照しながら上述されたような再構築技法の例に従って、ECコードに従って対象取引を回復させる。第6のフェーズ1060において、ネットワークノードR0は、ネットワークノードが回復されたことを示すACCEPTメッセージを他のネットワークノードに送る。
処理1000は、例証のためだけに4つのネットワークノードと共に実行されものとして示されているということに留意されたい。処理1000は、任意の適切な数のネットワークノードと共に実行されることが可能である。処理1000、QUERY_STATEメッセージのフォーマット、およびREPLY_STATEメッセージのフォーマットは、図11〜図12を参照しながら、より詳細に下記で論じられることになる。
図11は、本明細書の実装形態に従って実行されることが可能な分散システム(例えばブロックチェーンネットワーク102または212)におけるネットワークノードの回復処理を行うための処理1100の例を描写する。いくつかの実装形態において、処理1100は、1つまたは複数のコンピューティングデバイスを使用して実行される1つまたは複数のコンピュータ実行可能プログラムを使用して行われることが可能である。表現の明瞭さのために、続く説明は、全体的に、本説明における他の図の背景において方法1100を説明する。方法1100は、例えば任意の適切なシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって、必要に応じて行われることが可能であるということが理解されよう。いくつかの実装形態において、方法1100の様々なステップは、並行に、組み合わせて、ループさせて、または任意の順序で実行されることが可能である。
処理1100は、1106において始まり、ここで、ネットワークノード1102は、他のネットワークノード1104に状態要求メッセージをマルチキャストする。状態要求メッセージは、対象シーケンス番号の対象取引をネットワークノード1102が回復させることになるという指示を含む。ネットワークノード1102は、1次ノードまたはバックアップノードであることが可能である。
本明細書のいくつかの実装形態において、図12を参照すると、QUERY_STATEメッセージは、状態要求メッセージの例として、<j, seq>というフォーマットを有し、ここで、「j」は、QUERY_STATEメッセージを送るネットワークノード1102を表し、「seq」は、現在のコンセンサス処理におけるネットワークノード1102に対する最大のシーケンス番号または最も新しいシーケンス番号を表す。いくつかの実装形態において、QUERY_STATEメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
他のネットワークノード1104にQUERY_STATEメッセージをブロードキャストすることによって、ネットワークノード1102は、他のネットワークノードの最も新しいシーケンス番号をネットワークノード1102に送ることを、他のネットワークノード1104に要求しており、このことにより、ブロックチェーンシステムの最新のブロック情報を入手する。また、ブロックチェーンシステム全体の最新のブロック情報を入手することによって、ネットワークノード1102は、システム全体の最新のステータスに同期できる可能性があり、このことにより、ネットワークノード1102自体を回復させ、コンセンサス処理に参加し続ける。
図11を再度参照すると、1108において、他のネットワークノード1104のそれぞれは、状態要求メッセージの受領に応答して、状態リプライメッセージ(例えばREPLY_STATEメッセージ)をネットワークノード1102に送る。いくつかの実装形態において、状態リプライメッセージは、ネットワークノード1104と関連付けられた以前のシーケンス番号を含む。
いくつかの実装形態において、図12を参照すると、REPLY_STATEメッセージは、状態リプライメッセージの例として、<j, last_seq>というフォーマットを有し、ここで、「j」は、REPLY_STATEメッセージを送るネットワークノード1104を表し、「last_seq」は、現在のコンセンサス処理におけるネットワークノード1104に対する以前のシーケンス番号を表す。いくつかの実装形態において、REPLY_STATEメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
図11を再度参照すると、1110において、ネットワークノード1102は、受け取られた状態リプライメッセージの数が所定の閾値を超過するかどうかを判断する。例えば、ネットワークノード1102は、受け取られたREPLY_STATEメッセージの数が定足数(例えば2f+1またはn-f)を超過するかどうかを判断することができる。いくつかの実装形態において、ネットワークノード1102は、受け取られたREPLY_STATEメッセージの定足数が同一のシーケンス番号を含むかどうかをさらに判断する。受け取られたREPLY_STATEメッセージの定足数は、ネットワークノード1104の大多数がシステム全体の共通の状態に合意することを意味する同一のシーケンス番号を含む。
1112において、ネットワークノード1102は、ネットワークノード1104から受け取られた同一のシーケンス番号を含む状態リプライメッセージの数が所定の閾値を超過するとネットワークノード1102が判断すると、同一のシーケンス番号に基づいて対象シーケンス番号を判断する。例えば、ネットワークノード1102は、対象シーケンス番号が同一のシーケンス番号(例えば「last_seq」)の増分(例えば「last_seq+1」)であると判断することができる。
1114において、ネットワークノード1102は、要求メッセージ(例えばFETCH_ECHOメッセージ)を他のネットワークノード1104に送る。FETCH_ECHOメッセージは、他のネットワークノード1104のそれぞれからECHOメッセージを要求するために、ネットワークノード1102によって送られる。図3〜図6を参照しながら上記で論じられたように、ECHOメッセージは、対象取引に対するネットワークノード1104間のコンセンサスを実現するためにネットワークノード1104によって送信されたメッセージである。ECHOメッセージは、対象取引の一部(例えばECブロック)、およびECHOメッセージを送るネットワークノード1104の署名を含む。
いくつかの実装形態において、図12を参照すると、FETCH_ECHOメッセージは、要求メッセージの例として、<j, last_seq+1>というフォーマットを有し、ここで、「j」は、FETCH_ECHOメッセージを送るネットワークノード1102を表し、「last_seq+1」は、ネットワークノード1102が要求している他のネットワークノード1104からのECHOメッセージと関連付けられた対象シーケンス番号を表す。いくつかの実装形態において、FETCH_ECHOメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
本明細書で論じられるようなFETCH_ECHOメッセージは、他のネットワークノード1104からの最も新しいシーケンス番号または最大のシーケンス番号を含むECHOメッセージを要求するために、ネットワークノード1102によって送られる。他のネットワークノード1104からの最も新しいシーケンス番号または最大のシーケンス番号を含むECHOメッセージを収集することによって、ネットワークノード1102は、最も新しいシーケンス番号と関連付けられた最も新しい状態に回復させることができる可能性がある。
図11を再度参照すると、1116において、ネットワークノード1104のそれぞれは、FETCH_ECHOメッセージの受領に応答して、ネットワークノード1102にECHOメッセージを送る。いくつかの実装形態において、ネットワークノード1104のそれぞれは、ネットワークノード1102にECHOメッセージを送る前にFETCH_ECHOメッセージを検証する。いくつかの実装形態において、ネットワークノード1104のそれぞれは、FETCH_ECHOメッセージに含まれるシーケンス番号が、ネットワークノード1104と関連付けられた最も新しいシーケンス番号を超過しているかどうかを判断することによって、FETCH_ECHOメッセージを検証する。FETCH_ECHOメッセージに含まれるシーケンス番号が、ネットワークノード1104と関連付けられた最も新しいシーケンス番号に等しい場合、ネットワークノード1104は、FETCH_ECHOメッセージが有効であること、およびECHOメッセージがネットワークノード1102に送られることになると判断する。FETCH_ECHOメッセージに含まれるシーケンス番号が、ネットワークノード1104と関連付けられた最も新しいシーケンス番号を超過する場合、ネットワークノード1104は、FETCH_ECHOメッセージが無効であるということ、およびECHOメッセージがネットワークノード1102に送られることはないということを判断する。
1118において、ネットワークノード1102は、ネットワークノード1104によって送られたECHOメッセージが有効であるかどうかを検証する。いくつかの実装形態において、ネットワークノード1102は、マークル木を使用してECHOメッセージを検証する。例えば、ネットワークノード1102は、ECHOメッセージに含まれるデータを使用してマークル木を再構築し、再構築されたマークル木の再構築されたルートハッシュ値を判断することができる。ネットワークノード1102は、次に、再構築されたルートハッシュ値を、ECHOメッセージに含まれるルートハッシュ値と比較することができる。再構築されたルートハッシュ値が、ECHOメッセージに含まれるルートハッシュ値にマッチする場合、ネットワークノード1102は、ECHOメッセージが有効であると判断する。再構築されたルートハッシュ値が、ECHOメッセージに含まれるルートハッシュ値にマッチしない場合、ネットワークノード1102は、ECHOメッセージが無効であると判断し、無効のECHOメッセージを廃棄することができる。
いくつかの実装形態において、ネットワークノード1102は、ECHOメッセージ内の署名が有効であるかどうかをさらに検証することによって、ECHOメッセージが有効であるかどうかを検証する。例えば、ネットワークノード1102は、秘密鍵とペアになる公開鍵を使用してECHOメッセージ内の秘密鍵署名を認証して、署名を検証することができる。
1120において、ネットワークノード1102は、他のネットワークノード1104から受け取られた有効なECHOメッセージの数が所定の閾値を超過するかどうかを判断する。例えば、ネットワークノード1102は、他のネットワークノード1104から受け取られた有効なECHOメッセージの数が定足数(例えば2f+1)を超過するかどうかを判断することができる。
1122において、ネットワークノード1102は、有効なECHOメッセージの数が所定の閾値を超過するとの判断に応答して、対象シーケンス番号の対象取引を回復させる。いくつかの実装形態において、ネットワークノード1102は、いくつかの有効なECHOメッセージに含まれるデータを使用して対象取引を回復させる。例えば、ネットワークノード1102は、ECコードに従って対象取引を再構築するために、ECHOメッセージに含まれるECブロックのサブセットを取得することができる。
1124において、ネットワークノード1102は、対象取引を回復させた後、他のネットワークノード1104にACCEPTメッセージをマルチキャストする。例えば、ネットワークノード1102は、対象取引を成功裏に再構築した後、他のネットワークノード1104にACCEPTメッセージをマルチキャストすることができる。いくつかの実装形態において、ACCEPTメッセージは、ECHOメッセージ内の署名のセット、および対象シーケンス番号を含む。署名および対象シーケンス番号を含むACCEPTメッセージを他のネットワークノード1104に送ることによって、ネットワークノード1102は、ネットワークノード1102が回復し、システムの最新の状態に同期したことを他のネットワークノード1104に示す。
本明細書において上述されたような回復処理は、回復処理を実行するコンピュータの動作を改善し、ネットワークのボトルネックを緩和するのに役立つ多くの特徴を含む。例えば、本明細書における回復処理は、新しい1次ノードとして使用されるネットワークノードによって状態要求メッセージを送ること、他のネットワークノードから状態リプライメッセージを受け取ること、および他のネットワークノードからECHOメッセージを要求するためにネットワークノードによってFETCH_ECHOメッセージを送ること、を含む動作を含む。これらの動作は、故障しているネットワークノードの回復処理が、他の故障していないネットワークノード間のコンセンサス処理の正常動作に支障を来さないように行われる。これは、回復処理の複雑性を低減させることによって、故障しているネットワークノードを回復させるためのコンピューティングリソースおよびネットワークリソースを節約することを容易にする。
図13を参照すると、図13は、本明細書の実装形態によるコンセンサス装置1300のモジュールを示す図である。コンセンサスを実現するための装置1300は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。例えば、装置1300は、図1〜図6に示された実装形態に対応することが可能である。装置1300は、ブロックチェーンネットワーク内の1次ノードにおいて実行されることが可能である。装置1300は、取引要求を受け取るように構成された受信器または受信ユニット1302と、取引要求を使用してECコードに従っていくつかの消去コード(EC)ブロックを生成するように構成された生成ユニット1304と、いくつかの第1のメッセージを1つまたは複数のバックアップノードにそれぞれ送るように構成された送信器または送信ユニット1306であって、いくつかの第1のメッセージのそれぞれが、いくつかのECブロックと関連付けられた合成ハッシュ値を含む、送信器または送信ユニット1306と、バックアップノードのうちの少なくとも1つから少なくとも1つの第2のメッセージを受け取るようにさらに構成された受信器または受信ユニット1302であって、少なくとも1つの第2のメッセージが、いくつかの第1のメッセージのうちの1つ、およびいくつかの第1のメッセージのうちの1つと関連付けられたバックアップノードのうちの少なくとも1つの署名を含む、受信器または受信ユニット1302と、バックアップノードのうちの少なくとも1つからの少なくとも1つの第2のメッセージの受領に応答して、少なくとも1つの第2のメッセージが有効であるかどうかを検証するように構成された検証ユニット1308と、有効な第2のメッセージの数が所定の閾値を超過するかどうかを判断するように構成された判断ユニット1310と、有効な第2のメッセージの数が所定の閾値を超過するとの判断に応答して、ECコードに従っていくつかの有効な第2のメッセージのサブセットに基づいて取引要求を再構築するように構成された再構築ユニット1312と、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第3のメッセージを送るようにさらに構成された送信器または送信ユニット1306であって、第3のメッセージが、有効な第2のメッセージ内にある署名のセットを含む、送信器
または送信ユニット1306と、バックアップノードのうちの少なくとも1つから少なくとも1つの第3のメッセージを受け取るようにさらに構成された受信器または受信ユニット1302と、同一である所定の数の第3のメッセージの受領に応答して、取引要求を実行するように構成された実行ユニット1314と、を含む。
任意選択の実装形態において、取引要求は、シーケンス番号と関連付けられる。
任意選択の実装形態において、ECコードに従って複数のECブロックを生成することは、ECコードを使用して取引要求をECメッセージに変換することと、ECメッセージをいくつかのECブロックに分割することと、を含む。
任意選択の実装形態において、いくつかのECブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
任意選択の実装形態において、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
任意選択の実装形態において、いくつかの第1のメッセージのうちの1つと関連付けられたバックアップノードのうちの少なくとも1つの署名は、いくつかの第1のメッセージのうちの1つと関連付けられたバックアップノードのうちの少なくとも1つの秘密鍵署名を含む。
任意選択の実装形態において、少なくとも1つの第2のメッセージは、いくつかのECブロックのうちの少なくとも1つをさらに含む。
任意選択の実装形態において、少なくとも1つの第2のメッセージが有効であるかどうかを検証することは、少なくとも1つの第2のメッセージ内のいくつかのECブロックのうちの少なくとも1つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値が少なくとも1つの第2のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
任意選択の実装形態において、判断ユニット1310は、再構築された合成ハッシュ値が第2のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも1つの第2のメッセージが有効であると判断するようにさらに構成される。
任意選択の実装形態において、同一である所定の数の第3のメッセージは、署名の同一セットを有する所定の数の第3のメッセージを含む。
図13は、コンセンサス装置1300の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも1つのプロセッサと、少なくとも1つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
少なくとも1つのプロセッサは、取引要求を受け取ることと、取引要求を使用してECコードに従っていくつかの消去コード(EC)ブロックを生成することと、いくつかの第1のメッセージを1つまたは複数のバックアップノードにそれぞれ送ることであって、いくつかの第1のメッセージのそれぞれが、いくつかのECブロックと関連付けられた合成ハッシュ値を含む、送ることと、バックアップノードのうちの少なくとも1つから少なくとも1つの第2のメッセージを受け取ることであって、少なくとも1つの第2のメッセージが、いくつかの第1のメッセージのうちの1つ、およびいくつかの第1のメッセージのうちの1つと関連付けられたバックアップノードのうちの少なくとも1つの署名を含む、受け取ることと、バックアップノードのうちの少なくとも1つからの少なくとも1つの第2のメッセージの受領に応答して、少なくとも1つの第2のメッセージが有効であるかどうかを検証することと、有効な第2のメッセージの数が所定の閾値を超過するかどうかを判断することと、有効な第2のメッセージの数が所定の閾値を超過するとの判断に応答して、ECコードに従っていくつかの有効な第2のメッセージのサブセットに基づいて取引要求を再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第3のメッセージを送ることであって、第3のメッセージが、有効な第2のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも1つから少なくとも1つの第3のメッセージを受け取ることと、同一である所定の数の第3のメッセージの受領に応答して、取引要求を実行することと、を行うように構成される。
任意選択で、取引要求は、シーケンス番号と関連付けられる。
任意選択で、ECコードに従って複数のECブロックを生成することは、ECコードを使用して取引要求をECメッセージに変換することと、ECメッセージをいくつかのECブロックに分割することと、を含む。
任意選択で、いくつかのECブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
任意選択で、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
任意選択で、いくつかの第1のメッセージのうちの1つと関連付けられたバックアップノードのうちの少なくとも1つの署名は、いくつかの第1のメッセージのうちの1つと関連付けられたバックアップノードのうちの少なくとも1つの秘密鍵署名を含む。
任意選択で、少なくとも1つの第2のメッセージは、いくつかのECブロックのうちの少なくとも1つをさらに含む。
任意選択で、少なくとも1つの第2のメッセージが有効であるかどうかを検証することは、少なくとも1つの第2のメッセージ内のいくつかのECブロックのうちの少なくとも1つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値が少なくとも1つの第2のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
任意選択で、少なくとも1つのプロセッサは、再構築された合成ハッシュ値が第2のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも1つの第2のメッセージが有効であると判断するようにさらに構成される。
任意選択で、同一である所定の数の第3のメッセージは、署名の同一セットを有する所定の数の第3のメッセージを含む。
図14を参照すると、図14は、本明細書の実装形態によるコンセンサス装置1400のモジュールを示す図である。コンセンサスを実現するための装置1400は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置1400は、図1〜図6に示された実装形態に対応することが可能である。例えば、装置1400は、ブロックチェーンネットワークのバックアップノード内で実行されることが可能である。装置1400は、1次ノードから第1のメッセージを受け取るように構成された受信器または受信ユニット1402であって、第1のメッセージが、いくつかのECブロックと関連付けられた合成ハッシュ値を含み、いくつかのECブロックが、取引要求を使用してECコードに従って1次ノードによって生成される、受信器または受信ユニット1402と、第1のメッセージの受領に応答して、他のネットワークノードに第2のメッセージをバックアップノードによって送るように構成された送信器または送信ユニット1404であって、第2のメッセージが、第1のメッセージおよび第1のメッセージと関連付けられたバックアップノードの署名を含む、送信器または送信ユニット1404と、このバックアップノード以外の少なくとも1つのバックアップノードから少なくとも1つの第2のメッセージを受け取るようにさらに構成された受信器または受信ユニット1402と、少なくとも1つのバックアップノードからの少なくとも1つの第2のメッセージの受領に応答して、少なくとも1つの第2のメッセージが有効であるかどうかを検証するように構成された検証ユニット1406と、有効な第2のメッセージの数が所定の閾値を超過するかどうかを判断するように構成された判断ユニット1408と、有効な第2のメッセージの数が所定の閾値を超過するとの判断に応答して、ECコードに従っていくつかの有効な第2のメッセージのサブセットに基づいて取引要求を再構築するように構成された再構築ユニット1410と、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第3のメッセージを送るように構成された送信器または送信ユニット1404であって、第3のメッセージが、有効な第2のメッセージ内にある署名のセットを含む、送信器または送信ユニット1404と、バックアップノードのうちの少なくとも1つ
から少なくとも1つの第3のメッセージを受け取るようにさらに構成された受信器または受信ユニット1402と、同一である所定の数の第3のメッセージの受領に応答して、取引要求を実行するように構成された実行ユニット1412と、を含む。
任意選択の実装形態において、ECコードに従って複数のECブロックを生成することは、ECコードを使用して取引要求をECメッセージに変換することと、ECメッセージをいくつかのECブロックに分割することと、を含む。
任意選択の実装形態において、複数のECブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
任意選択の実装形態において、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
任意選択の実装形態において、第1のメッセージと関連付けられたバックアップノードの署名は、第1のメッセージと関連付けられたバックアップノードの秘密鍵署名を含む。
任意選択の実装形態において、少なくとも1つの第2のメッセージは、いくつかのECブロックのうちの少なくとも1つをさらに含む。
任意選択の実装形態において、少なくとも1つの第2のメッセージが有効であるかどうかを検証することは、少なくとも1つの第2のメッセージ内のいくつかのECブロックのうちの少なくとも1つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値を少なくとも1つの第2のメッセージ内の合成ハッシュ値と比較することと、再構築された合成ハッシュ値が少なくとも1つの第2のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
任意選択の実装形態において、判断ユニット1408は、再構築された合成ハッシュ値が第2のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも1つの第2のメッセージが有効であると判断するようにさらに構成される。
任意選択の実装形態において、同一である所定の数の第3のメッセージは、署名の同一セットを有する所定の数の第3のメッセージを含む。
図14は、コンセンサス装置1400の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも1つのプロセッサと、少なくとも1つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
少なくとも1つのプロセッサは、1次ノードから第1のメッセージを受け取ることであって、第1のメッセージが、いくつかのECブロックと関連付けられた合成ハッシュ値を含み、いくつかのECブロックが、取引要求を使用してECコードに従って1次ノードによって生成される、受け取ることと、第1のメッセージの受領に応答して、他のネットワークノードに第2のメッセージをバックアップノードによって送ることであって、第2のメッセージが、第1のメッセージおよび第1のメッセージと関連付けられたバックアップノードの署名を含む、送ることと、このバックアップノード以外の少なくとも1つのバックアップノードから少なくとも1つの第2のメッセージを受け取ることと、少なくとも1つのバックアップノードからの少なくとも1つの第2のメッセージの受領に応答して、少なくとも1つの第2のメッセージが有効であるかどうかを検証することと、有効な第2のメッセージの数が所定の閾値を超過するかどうかを判断することと、有効な第2のメッセージの数が所定の閾値を超過するとの判断に応答して、ECコードに従っていくつかの有効な第2のメッセージのサブセットに基づいて取引要求を再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第3のメッセージを送ることであって、第3のメッセージが、有効な第2のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも1つから少なくとも1つの第3のメッセージを受け取ることと、同一である所定の数の第3のメッセージの受領に応答して、取引要求を実行することと、を行うように構成される。
任意選択で、ECコードに従って複数のECブロックを生成することは、ECコードを使用して取引要求をECメッセージに変換することと、ECメッセージをいくつかのECブロックに分割することと、を含む。
任意選択で、複数のECブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
任意選択で、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
任意選択で、第1のメッセージと関連付けられたバックアップノードの署名は、第1のメッセージと関連付けられたバックアップノードの秘密鍵署名を含む。
任意選択で、少なくとも1つの第2のメッセージは、いくつかのECブロックのうちの少なくとも1つをさらに含む。
任意選択で、少なくとも1つの第2のメッセージが有効であるかどうかを検証することは、少なくとも1つの第2のメッセージ内のいくつかのECブロックのうちの少なくとも1つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値を少なくとも1つの第2のメッセージ内の合成ハッシュ値と比較することと、再構築された合成ハッシュ値が少なくとも1つの第2のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
任意選択で、少なくとも1つのプロセッサは、再構築された合成ハッシュ値が第2のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも1つの第2のメッセージが有効であると判断するようにさらに構成される。
任意選択で、同一である所定の数の第3のメッセージは、署名の同一セットを有する所定の数の第3のメッセージを含む。
図15を参照すると、図15は、本明細書の実装形態による1次ノード変更装置1500のモジュールを示す図である。1次ノードを変更するための装置1500は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置1500は、図7〜図9において示された実装形態に対応することが可能である。例えば、装置1500は、ブロックチェーンネットワークのバックアップノードにおいて実行されることが可能である。装置1500は、エポック変更が行われる必要があると判断するように構成された判断ユニット1502であって、エポック変更は、現在の1次ノードによる現在のエポックから、新しい1次ノードによる新しいエポックへの変更を引き起こし、現在のエポックは、1次ノードを使用していくつかのネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含み、コンセンサス処理が3つのフェーズを含む、判断ユニット1502と、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断するようにさらに構成された判断ユニット1502であって、重みが、新しい1次ノードになるためのバックアップノードの資格の測定基準である、判断ユニット1502と、現在のエポックにおける3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みに基づいてバックアップノードに対する加重和を判断するようにさらに構成された判断ユニット1502と、加重和が第1の所定の閾値に達したとの判断に応答して、このネットワークノード以外のいくつかのネットワークノードにEPOCH_CHANGEメッセージを送るように構成された送信器または送信ユニット1504であって、EPOCH_CHANGEメッセージが、現在の1次ノードによる現在のエポックから、バックアップノードが新しい1次ノードである新しいエポックへの変更のための要求を示し、EPOCH_CHANGEメッセージがバックアップノードの加重和を含む、送信器または送信ユニット1504と、このバックアップノード以外のいくつかのネットワークノードのうちの少なくとも1つから少なくとも1つのNEW_EPOCHメッセージを受け取るように構成された受信器または受信ユニット1506であって、NEW_EPOCHメッセージが、新しい1次
ノードにバックアップノードがなることについての承認を示す、受信器または受信ユニット1506と、少なくとも1つのNEW_EPOCHメッセージが有効であるかどうかを検証するように構成された検証ユニット1508と、少なくとも1つのNEW_EPOCHメッセージからの有効なNEW_EPOCHメッセージの数が第2の所定の閾値を超過するかどうかを判断するようにさらに構成された判断ユニット1502と、有効なNEW_EPOCHメッセージの数が第2の所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい1次ノードであると判断するようにさらに構成された判断ユニット1502と、を含む。
任意選択の実装形態において、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、コンセンサス処理の第1のフェーズに対するバックアップノードの重みが第1の値であると判断することを含む。
任意選択の実装形態において、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第2のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第2のフェーズに対するバックアップノードの重みが第1の値であると判断することと、現在のエポックにおけるコンセンサス処理の第2のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第2のフェーズに対するバックアップノードの重みが第2の値であると判断することであって、第1の値が第2の値より小さい、判断することと、を含む。
任意選択の実装形態において、ネットワークノードに対する第2のフェーズにおける定足数検証は、他のネットワークノードから所定の数のECHOメッセージを受け取ることを含む。
任意選択の実装形態において、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第3のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第3のフェーズに対するバックアップノードの重みが第3の値であると判断することと、現在のエポックにおけるコンセンサス処理の第3のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第3のフェーズに対するバックアップノードの重みが第4の値であると判断することであって、第3の値が第4の値より小さい、判断することと、を含む。
任意選択の実装形態において、ネットワークノードに対する第3のフェーズにおける定足数検証は、他のネットワークノードから所定の数の受け入れメッセージを受け取ることであって、他のネットワークノードからの受け入れメッセージのそれぞれが、他のネットワークノードのそれぞれが所定の数のECHOメッセージを受け入れたことを示す、受け取ることを含む。
任意選択の実装形態において、EPOCH_CHANGEメッセージは、いくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットをさらに含み、NEW_EPOCHメッセージは、EPOCH_CHANGEメッセージのダイジェストを含む。
任意選択の実装形態において、少なくとも1つの有効なNEW_EPOCHメッセージが有効であるかどうかを検証することは、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することは、EPOCH_CHANGEメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
任意選択の実装形態において、エポック変更が行われる必要があると判断することは、所定の期間内に古いエポックにおいてコンセンサスが実現されなかったとの判断に応答して、エポック変更が行われる必要があると判断することを含む。
任意選択の実装形態において、1次ノード変更装置1500は、新しい1次ノードによる新しいエポックにおいて動作するように構成された動作ユニット1510であって、新しいエポックが、新しい1次ノードを使用して複数のネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含む、動作ユニット1510をさらに含む。
図15は、1次ノード変更装置1500の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも1つのプロセッサと、少なくとも1つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
少なくとも1つのプロセッサは、エポック変更が行われる必要があると判断することであって、エポック変更が、現在の1次ノードによる現在のエポックから、新しい1次ノードによる新しいエポックへの変更を引き起こし、現在のエポックが、1次ノードを使用していくつかのネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含み、コンセンサス処理が3つのフェーズを含む、判断することと、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することであって、重みが、新しい1次ノードになるためのバックアップノードの資格の測定基準である、判断することと、現在のエポックにおける3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みに基づいてバックアップノードに対する加重和を判断することと、加重和が第1の所定の閾値に達したとの判断に応答して、このネットワークノード以外のいくつかのネットワークノードにEPOCH_CHANGEメッセージを送ることであって、EPOCH_CHANGEメッセージが、現在の1次ノードによる現在のエポックから、バックアップノードが新しい1次ノードである新しいエポックへの変更のための要求を示し、EPOCH_CHANGEメッセージがバックアップノードの加重和を含む、送ることと、このバックアップノード以外のいくつかのネットワークノードのうちの少なくとも1つから少なくとも1つのNEW_EPOCHメッセージを受け取ることであって、NEW_EPOCHメッセージが、新しい1次ノードにバックアップノードがなることについての承認を示す、受け取ることと、少なくとも1つのNEW_EPOCHメッセージが有効であるかどうかを検証することと、少なくとも1つのNEW_EPOCHメッセージからの有効なNEW_EPOCHメッセージの数が第2の所定の閾値を超過するかどうかを判断することと、有効なNEW_EPOCHメッセージの数が第2の所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい1次ノードであると判断することと、を行うように構成される。
任意選択で、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、コンセンサス処理の第1のフェーズに対するバックアップノードの重みが第1の値であると判断すること含む。
任意選択で、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第2のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第2のフェーズに対するバックアップノードの重みが第1の値であると判断することと、現在のエポックにおけるコンセンサス処理の第2のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第2のフェーズに対するバックアップノードの重みが第2の値であると判断することであって、第1の値が第2の値より小さい、判断することと、を含む。
任意選択で、ネットワークノードに対する第2のフェーズにおける定足数検証は、他のネットワークノードから所定の数のECHOメッセージを受け取ることを含む。
任意選択で、現在のエポックにおけるコンセンサス処理の3つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第3のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第3のフェーズに対するバックアップノードの重みが第3の値であると判断することと、現在のエポックにおけるコンセンサス処理の第3のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第3のフェーズに対するバックアップノードの重みが第4の値であると判断することであって、第3の値が第4の値より小さい、判断することと、を含む。
任意選択で、ネットワークノードに対する第3のフェーズにおける定足数検証は、他のネットワークノードから所定の数の受け入れメッセージを受け取ることであって、他のネットワークノードからの受け入れメッセージのそれぞれが、他のネットワークノードのそれぞれが所定の数のECHOメッセージを受け入れたことを示す、受け取ることを含む。
任意選択で、EPOCH_CHANGEメッセージは、いくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットをさらに含み、NEW_EPOCHメッセージは、EPOCH_CHANGEメッセージのダイジェストを含む。
任意選択で、少なくとも1つの有効なNEW_EPOCHメッセージが有効であるかどうかを検証することは、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することが、EPOCH_CHANGEメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
任意選択で、エポック変更が行われる必要があると判断することは、所定の期間内に古いエポックにおいてコンセンサスが実現されなかったとの判断に応答して、エポック変更が行われる必要があると判断することを含む。
任意選択で、少なくとも1つのプロセッサは、新しい1次ノードによる新しいエポックにおいて動作するようにさらに構成され、新しいエポックは、新しい1次ノードを使用して複数のネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含む。
図16を参照すると、図16は、本明細書の実装形態による1次ノード変更装置1600のモジュールを示す図である。1次ノードを変更するための装置1600は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置1600は、図7〜図9において示された実装形態に対応する。例えば、装置1600は、ブロックチェーンネットワークのネットワークノードにおいて実行されることが可能である。装置1600は、このネットワークノード以外のバックアップノードからEPOCH_CHANGEメッセージを受け取るように構成された受信器または受信ユニット1602であって、EPOCH_CHANGEメッセージが、エポック変更が行われる必要があるという指示を含み、エポック変更が、現在の1次ノードによる現在のエポックから、新しい1次ノードによる新しいエポックへの変更を引き起こす、受信器または受信ユニット1602と、EPOCH_CHANGEメッセージが有効であるかどうかを検証するように構成された検証ユニット1604と、EPOCH_CHANGEメッセージが有効であることの検証に応答して、他のネットワークノードにNEW_EPOCHメッセージを送るように構成された送信器または送信ユニット1606であって、NEW_EPOCHメッセージが、EPOCH_CHANGEメッセージのダイジェストを含む、送信器または送信ユニット1606と、このネットワークノード以外のいくつかのネットワークノードのうちの少なくとも1つから少なくとも1つのNEW_EPOCHメッセージを受け取るようにさらに構成された受信器または受信ユニット1602と、少なくとも1つのNEW_EPOCHメッセージが有効であるかどうかを検証するようにさらに構成された検証ユニット1604と、少なくとも1つのNEW_EPOCHメッセージからの有効なNEW_EPOCHメッセージの数が所定の閾値を超過するかどうかを判断するように構成された判断ユニット1608と、有効なNEW_EPOCHメッセージの数が所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい1次ノードであると判断するようにさらに構成された判断ユニット1608と、を含む。
任意選択の実装形態において、EPOCH_CHANGEメッセージは、バックアップノードと関連付けられた加重和、およびいくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットを含む。
任意選択の実装形態において、EPOCH_CHANGEメッセージが有効であるかどうかを検証することは、EPOCH_CHANGEメッセージ内の加重和が有効であるかどうかを検証することを含み、EPOCH_CHANGEメッセージ内の加重和が有効であるかどうかを検証することは、署名のセットが有効であるかどうかを検証することを含む。
任意選択の実装形態において、少なくとも1つのNEW_EPOCHメッセージが有効であるかどうかを検証することは、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することは、EPOCH_CHANGEメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
図16は、1次ノード変更装置1600の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも1つのプロセッサと、少なくとも1つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
少なくとも1つのプロセッサは、このネットワークノード以外のバックアップノードからEPOCH_CHANGEメッセージを受け取ることであって、EPOCH_CHANGEメッセージが、エポック変更が行われる必要があるという指示を含み、エポック変更が、現在の1次ノードによる現在のエポックから、新しい1次ノードによる新しいエポックへの変更を引き起こす、受け取ることと、EPOCH_CHANGEメッセージが有効であるかどうかを検証することと、EPOCH_CHANGEメッセージが有効であることの検証に応答して、他のネットワークノードにNEW_EPOCHメッセージを送ることであって、NEW_EPOCHメッセージが、EPOCH_CHANGEメッセージのダイジェストを含む、送ることと、このネットワークノード以外のいくつかのネットワークノードのうちの少なくとも1つから少なくとも1つのNEW_EPOCHメッセージを受け取ることと、少なくとも1つのNEW_EPOCHメッセージが有効であるかどうかを検証することと、少なくとも1つのNEW_EPOCHメッセージからの有効なNEW_EPOCHメッセージの数が所定の閾値を超過するかどうかを判断することと、有効なNEW_EPOCHメッセージの数が所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい1次ノードであると判断することと、を行うように構成される。
任意選択で、EPOCH_CHANGEメッセージは、バックアップノードと関連付けられた加重和、およびいくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットを含む。
任意選択で、EPOCH_CHANGEメッセージが有効であるかどうかを検証することは、EPOCH_CHANGEメッセージ内の加重和が有効であるかどうかを検証することを含み、EPOCH_CHANGEメッセージ内の加重和が有効であるかどうかを検証することは、署名のセットが有効であるかどうかを検証することを含む。
任意選択で、少なくとも1つのNEW_EPOCHメッセージが有効であるかどうかを検証することが、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも1つのNEW_EPOCHメッセージ内のEPOCH_CHANGEメッセージのダイジェストが有効であるかどうかを検証することが、EPOCH_CHANGEメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
図17を参照すると、図17は、本明細書の実装形態による回復装置1700のモジュールを示す図である。回復のための装置1700は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置1700は、図10〜図12において示された実装形態に対応することが可能である。例えば、装置1700は、ブロックチェーンネットワークのネットワークノード内で実行されることが可能である。装置1700は、ブロックチェーンネットワークのいくつかの他のネットワークノードに状態要求メッセージをブロックチェーンネットワークのネットワークノードによってブロードキャストするように構成されたブロードキャストユニット1702であって、ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ブロードキャストユニット1702と、いくつかの他のネットワークノードからいくつかの状態リプライメッセージを受け取るように構成された受信器1704または受信ユニット1704であって、いくつかの状態リプライメッセージのそれぞれがシーケンス番号を含む、受信器1704または受信ユニット1704と、状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて対象シーケンス番号を識別するように構成された識別ユニット1706であって、いくつかの状態メッセージのそれぞれが同じシーケンス番号を含む、識別ユニット1706と、いくつかの他のネットワークノードに要求メッセージを送るように構成された送信器1708または送信ユニット1708であって、要求メッセージが、いくつかの他のネットワークノードのそれぞれからのECHOメッセージを要求し、ECHOメッセージが、対象シーケンス番号を有する対象取引に対するいくつかの他のネットワークノード間のコンセンサスを実現するためにいくつかの他のネットワークノードのそれぞれによって送信されたメッセージであり、ECHOメッセージが、対象取引の一部、およびいくつかの他のネットワークノードのそれぞれの署名を含む、送信器1708または送信ユニット1708と、いくつかの他のネットワークノードからいくつかのECHOメッセージを受け取るようにさらに構成された受信器1704または受信ユニット1704と、いくつかのECHOメッセージからいくつかの有
効なECHOメッセージを判断するように構成された判断ユニット1710であって、いくつかの有効なECHOメッセージのそれぞれが対象シーケンス番号を含む、判断ユニット1710と、有効なECHOメッセージの数が所定の閾値を超過するとの判断に応答して、いくつかの有効なECHOメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させるように構成された回復ユニット1712と、ネットワークノードが回復されたことを示すメッセージをいくつかの他のネットワークノードに送るようにさらに構成された送信器1708と、を含む。
任意選択の実装形態において、いくつかのネットワークノードは、1次ノードおよび1つまたは複数のバックアップノードを含む。
任意選択の実装形態において、ネットワークノードは、1次ノードまたはバックアップノードである。
任意選択の実装形態において、要求メッセージは、対象シーケンス番号を含む。
任意選択の実装形態において、回復装置1700は、ネットワークノードにECHOメッセージを送る前に、要求メッセージをこのネットワークノード以外のいくつかの他のネットワークノードのそれぞれによって検証するように構成された検証ユニット1714をさらに含む。
任意選択の実装形態において、検証ユニット1714は、ECHOメッセージのそれぞれが有効であるかどうかを検証するようにさらに構成され、ECHOメッセージのそれぞれが有効であるかどうかを検証することは、マークル木を使用してECHOメッセージのそれぞれが有効であるかどうかを検証することを含む。
任意選択の実装形態において、ECHOメッセージのそれぞれが有効であるかどうかを検証することは、ECHOメッセージ内の署名が有効であるかどうかを検証することをさらに含む。
任意選択の実装形態において、ECHOメッセージのそれぞれは、対象取引と関連付けられたいくつかの消去コード(EC)ブロックのうちの少なくとも1つをさらに含み、いくつかのECブロックは、対象取引を使用してECコードに従って生成される。
任意選択の実装形態において、いくつかの有効なECHOメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることは、いくつかの有効なECHOメッセージ内にある複数のECブロックのサブセットを使用して対象取引を再構築することを含む。
任意選択の実装形態において、ネットワークノードが回復されたことを示すいくつかの他のネットワークノードへのメッセージは、いくつかの有効なECHOメッセージ内の署名のセット、および対象シーケンス番号を含む。
以前の実装形態において示されたシステム、装置、モジュール、またはユニットは、コンピュータチップまたはエンティティを使用することによって実行されることが可能であり、また一定の機能を有する製品を使用することによって実行されることが可能である。典型的な実行デバイスはコンピュータであり、コンピュータは、パーソナルコンピュータ、ラップトップコンピュータ、セルラー電話、カメラ電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、eメール送受信デバイス、ゲーム機、タブレット型コンピュータ、ウェアラブルデバイス、またはこれらのデバイスの任意の組合せであることが可能である。
装置内の各ユニットの機能および役割の実行処理については、以前の方法における対応するステップの実行処理に対する参照が行われることが可能である。簡略化のために詳細はここでは省略される。
装置の実装形態は基本的に方法の実装形態に対応するので、関連部分については、方法の実装形態における関連説明に対する参照が行われることが可能である。前述の装置の実装形態は、1つの例にすぎない。別々の部分として説明されたユニットは、物理的に別のものであっても、そうでなくてもよく、ユニットとして表示された部分は、物理的なユニットであっても、そうでなくてもよく、1つの場所に配置されてもよく、また複数のネットワークユニット上に分散されてもよい。モジュールのいくつかまたは全ては、本明細書の解決策の目的を実現するための実際の要望に基づいて選択されることが可能である。当業者は、創造的な努力をすることなく本出願の実装形態を理解し実行することができる。
図17は、回復装置1700の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも1つのプロセッサと、少なくとも1つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
少なくとも1つのプロセッサは、ブロックチェーンネットワークのいくつかの他のネットワークノードに状態要求メッセージをブロックチェーンネットワークのネットワークノードによってブロードキャストすることであって、ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ブロードキャストすることと、いくつかの他のネットワークノードからいくつかの状態リプライメッセージを受け取ることであって、いくつかの状態リプライメッセージのそれぞれがシーケンス番号を含む、受け取ることと、状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて対象シーケンス番号を識別することであって、いくつかの状態メッセージのそれぞれが同じシーケンス番号を含む、識別することと、いくつかの他のネットワークノードに要求メッセージを送ることであって、要求メッセージが、いくつかの他のネットワークノードのそれぞれからのECHOメッセージを要求し、ECHOメッセージが、対象シーケンス番号を有する対象取引に対するいくつかの他のネットワークノード間のコンセンサスを実現するためにいくつかの他のネットワークノードのそれぞれによって送信されたメッセージであり、ECHOメッセージが、対象取引の一部、およびいくつかの他のネットワークノードのそれぞれの署名を含む、送ることと、複数の他のネットワークノードからいくつかのECHOメッセージを受け取ることと、いくつかのECHOメッセージからいくつかの有効なECHOメッセージを判断することであって、いくつかの有効なECHOメッセージのそれぞれが対象シーケンス番号を含む、判断することと、有効なECHOメッセージの数が所定の閾値を超過するとの判断に応答して、いくつかの有効なECHOメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることと、ネットワークノードが回復されたことを示すメッセージをいくつかの他のネットワークノードに送ることと、を行うように構成される。
任意選択で、いくつかのネットワークノードは、1次ノードおよび1つまたは複数のバックアップノードを含む。
任意選択で、ネットワークノードは、1次ノードまたはバックアップノードである。
任意選択で、要求メッセージは、対象シーケンス番号を含む。
任意選択で、少なくとも1つのプロセッサは、ネットワークノードにECHOメッセージを送る前に、要求メッセージをこのネットワークノード以外のいくつかの他のネットワークノードのそれぞれによって検証するようにさらに構成される。
任意選択で、少なくとも1つのプロセッサは、ECHOメッセージのそれぞれが有効であるかどうかを検証することであって、ECHOメッセージのそれぞれが有効であるかどうかを検証することが、マークル木を使用してECHOメッセージのそれぞれが有効であるかどうかを検証することを含む、検証すること、を行うようにさらに構成される。
任意選択で、ECHOメッセージのそれぞれが有効であるかどうかを検証することは、ECHOメッセージ内の署名が有効であるかどうかを検証することをさらに含む。
任意選択で、ECHOメッセージのそれぞれは、対象取引と関連付けられたいくつかの消去コード(EC)ブロックのうちの少なくとも1つをさらに含み、いくつかのECブロックは、対象取引を使用してECコードに従って生成される。
任意選択で、いくつかの有効なECHOメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることは、いくつかの有効なECHOメッセージ内にあるいくつかのECブロックのサブセットを使用して対象取引を再構築することを含む。
任意選択で、ネットワークノードが回復されたことを示すいくつかの他のネットワークノードへのメッセージは、いくつかの有効なECHOメッセージ内の署名のセット、および対象シーケンス番号を含む。
本明細書において説明された主題の実装形態ならびにアクションおよび動作は、デジタル電子回路機器において、現実に具現化されたコンピュータソフトウェアもしくはファームウェアにおいて、本明細書およびこれらの構造上の均等物の中で開示された構造を含むコンピュータハードウェアにおいて、またはこれらの1つもしくは複数の組合せにおいて実行されることが可能である。本明細書において説明された主題の実装形態は、データ処理装置による実行のため、またはデータ処理装置の動作を制御するために、コンピュータプログラム担体上でエンコードされた、例えばコンピュータプログラム命令の1つまたは複数のモジュールといった、1つまたは複数のコンピュータプログラムとして実行されることが可能である。担体は、有形の非一時的コンピュータストレージ媒体であることが可能である。一方、またはさらに、担体は、データ処理装置による実行のために適切な受信装置に送信するための情報をエンコードするために生成される、例えば、機械生成された電気的、光学的、または電磁気的な信号といった、人工的に生成された伝搬信号であることが可能である。コンピュータストレージ媒体は、機械可読ストレージデバイス、機械可読ストレージ基板、ランダムもしくはシリアルアクセスメモリデバイス、またはこれらの1つもしくは複数の組合せであることが可能であり、またこれらの一部であることが可能である。コンピュータストレージ媒体は、伝搬信号ではない。
用語「データ処理装置」は、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサもしくはコンピュータを例として含む、データを処理するための装置、デバイス、および機械の全ての種類を包含する。データ処理装置は、例えばFPGA(フィールドプログラマブルゲートアレイ)、ASIC(特定用途向け集積回路)、またはGPU(グラフィックス処理ユニット)といった特殊用途のロジック回路機器を含むことができる。装置は、ハードウェアの他に、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの1つまたは複数の組合せを構成するコードといった、コンピュータプログラムのための実行環境を作り出すコードを含むこともできる。
プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリ、モジュール、ソフトウェアモジュール、エンジン、スクリプト、もしくはコードと呼ばれること、またはこれらとして説明されることが可能なコンピュータプログラムは、コンパイルもしくは翻訳された言語、または宣言型言語もしくは手続き型言語を含む、プログラミング言語の任意の形式で書き込まれることが可能であり、コンピュータプログラムは、スタンドアロンプログラムとして、あるいはモジュール、コンポーネント、エンジン、サブルーチン、または1つもしくは複数の場所においてデータ通信ネットワークによって相互接続された1つもしくは複数のコンピュータを含むことができるコンピューティング環境における実行に適した他のユニットとして含む、任意の形式で導入されることが可能である。
コンピュータプログラムは、ファイルシステムにおけるファイルに対応することができるが、そうである必要はない。コンピュータプログラムは、例えば、マークアップ言語文書に、当該のプログラムに専用の単一のファイルに、または例えば、1つもしくは複数のモジュール、サブプログラム、もしくはコードの一部を格納するファイルといった、複数のコーディネイテッドファイルに格納された1つまたは複数のスクリプトといった、他のプログラムまたはデータを保持するファイルの一部に格納されることが可能である。
本明細書において説明された処理およびロジックフローは、1つまたは複数のコンピュータプログラムを実行して、入力データに対して演算し、出力を生成することによって動作を行う、1つまたは複数のコンピュータによって行われることが可能である。処理およびロジックフローは、例えば、FPGA、ASIC、もしくはGPUといった特殊用途のロジック回路機器によって、または特殊用途のロジック回路機器および1つもしくは複数のプログラムされたコンピュータの組合せによって行われることも可能である。
コンピュータプログラムの実行に適したコンピュータは、汎用もしくは特殊用途のマイクロプロセッサまたは両方、あるいは他の任意の種類の中央処理装置に基づくことが可能である。一般に、中央処理装置は、リードオンリメモリもしくはランダムアクセスメモリまたは両方から命令およびデータを受け取ることになる。コンピュータの要素は、命令を実行するための中央処理装置、ならびに命令およびデータを格納するための1つまたは複数のメモリデバイスを含むことができる。中央処理装置およびメモリは、特殊用途のロジック回路機器によって補われることも、特殊用途のロジック回路機器に組み込まれることも可能である。
一般に、コンピュータは、(コンピュータ可読メモリとも呼ばれる)少なくとも1つの非一時的コンピュータ可読記憶媒体に連結されることになる。コンピュータに連結されたストレージ媒体は、コンピュータの内部構成要素(例えば統合されたハードドライブ)、または外部構成要素(例えば、ユニバーサルシリアルバス(USB)ハードドライブもしくはネットワークを超えてアクセスされるストレージシステム)であることが可能である。ストレージ媒体の例は、例えば、磁気ディスク、光磁気ディスク、もしくは光ディスク、ソリッドステートデバイス、クラウドストレージシステムなどのネットワークストレージリソース、またはストレージ媒体の他のタイプを含むことができる。しかし、コンピュータは、このようなデバイスを有する必要はない。さらに、コンピュータは、例えば、ほんの数例を挙げれば、携帯電話、パーソナルデジタルアシスタント(PDA)、モバイルオーディオプレーヤもしくはモバイルビデオプレーヤ、ゲーム機、全地球測位システム(GPS)受信器、または例えばユニバーサルシリアルバス(USB)フラッシュドライブといった携帯型ストレージデバイスといった、別のデバイスに組み込まれることが可能である。
ユーザとの対話を行うために、本明細書において説明された主題の実装形態は、ユーザに情報を表示するための例えばLCD(液晶ディスプレイ)モニタといった表示デバイス、ならびに例えばキーボード、および例えばマウス、トラックボールもしくはタッチパッドといったポインティングデバイスといった、ユーザがコンピュータに入力することができる入力デバイスを有するコンピュータ上で実行されること、またはこのコンピュータと通信するように構成されることが可能である。同様にユーザとの対話を行うために他の種類のデバイスが使用されることが可能であり、例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックといった、知覚によるフィードバックの任意の形式であることが可能であり、ユーザからの入力は、音響、会話、または触知入力を含む任意の形式で受け取られることが可能である。さらに、コンピュータは、例えば、ウェブブラウザから受け取られた要求に応答して、ユーザのデバイス上のウェブブラウザにウェブページを送ることによって、または例えばスマートフォンもしくは電子タブレットといったユーザデバイス上で動くアプリと対話することによって、ユーザによって使用されるデバイスとの間で文書をやりとりすることによってユーザと対話することができる。同様に、コンピュータは、例えば、メッセージングアプリケーションを動かしているスマートフォンといった個人のデバイスにテキストメッセージまたは他の形式のメッセージを送ること、および返信としてユーザから応答メッセージを受け取ることによって、ユーザと対話することができる。
本明細書は、システム、装置、およびコンピュータプログラム構成要素に関連して用語「ように構成される(configured to)」を使用する。1つまたは複数のコンピュータのシステムが特定の動作またはアクションを行うように構成されることは、動作中に動作またはアクションをシステムに行わせる、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せをシステムがシステム上にインストールしたということを意味する。1つまたは複数のコンピュータプログラムが特定の動作またはアクションを行うように構成されることは、データ処理装置によって実行されると、動作またはアクションを装置に行わせる命令を1つまたは複数のプログラムが含むということを意味する。特殊用途のロジック回路機器が特定の動作またはアクションを行うように構成されることは、動作またはアクションを行う電子ロジックを回路機器が有するということを意味する。
本明細書は、多くの特定の実装形態の詳細を収めるが、これらは、特許請求の範囲自体によって定義される特許請求されるものの範囲を限定するものと解釈されるべきではなく、むしろ特定の実装形態に固有であることが可能な特徴の説明として解釈されるべきである。別々の実装形態の背景において本明細書において説明される一定の特徴は、単一の実装形態における組合せの中で実現されることも可能である。逆に、単一の実装形態の背景において説明される様々な特徴は、複数の実装形態において別々に、または任意の適切なサブコンビネーションにおいて実現されることも可能である。さらに、特徴は、一定の組合せにおいて作用するものとして上述されることがあり、したがって最初であったとしても特許請求されることがあるが、特許請求される組合せからの1つまたは複数の特徴は、いくつかのケースにおいて、組合せから削除されることが可能であり、特許請求の範囲は、サブコンビネーションまたはサブコンビネーションの変形形態を対象とすることが可能である。
同様に、特定の順序で、図面において動作が描写され、特許請求の範囲において列挙されるが、これは、示された特定の順序で、もしくは連続した順序でこのような動作が行われること、または全ての図示された動作が望ましい結果を実現するために行われることが必要であると見なされるべきではない。一定の状況において、マルチタスク処理および並列処理が有利なこともある。さらに、上述の実装形態における様々なシステムモジュールおよび構成要素の分離は、全ての実装形態においてこのような分離が必要であると見なされるべきではなく、説明されたプログラム構成要素およびシステムは、全体的に、単一のソフトウェア製品に相互に統合されることも、複数のソフトウェア製品にパッケージ化されることも可能であるということを理解されたい。
主題の特定の実装形態が説明された。他の実装形態は、以下の特許請求の範囲の範囲内にある。例えば、特許請求の範囲において列挙されるアクションは、様々な順序で行われることが可能であり、依然として望ましい結果を実現する。1つの例として、添付の図において描写された処理は、望ましい結果を実現するために、示された特定の順序、または連続した順序を必ずしも必要としない。いくつかのケースにおいて、マルチタスク処理および並列処理が有利なこともある。
100 環境、システム
102 コンソーシアムブロックチェーンネットワーク、ブロックチェーンネットワーク
106 コンピューティングデバイスまたはシステム
108 コンピューティングデバイスまたはシステム
110 ネットワーク
200 概念アーキテクチャ、システム
202 参加者システム
204 参加者システム
206 参加者システム
212 ブロックチェーンネットワーク
214 ノード
216 ブロックチェーン
216' 完全コピー
216'' 完全コピー
216''' 完全コピー
300 処理、コンセンサス処理、システム
310 ステージ、第1のフェーズ、フェーズ1: INITIALメッセージ
320 ステージ、第2のフェーズ、フェーズ2: ECHOメッセージ
330 ステージ、第3のフェーズ、フェーズ3: ACCEPTメッセージ
400 処理、コンセンサス処理
402 クライアントノード
404 1次ノード、ノード
406 バックアップノード
408 取引要求を生成する
410 取引要求
412 ECブロックを生成する
414 INITIALメッセージを生成する
416 INITIALメッセージ
418 ECHOメッセージを生成する
420 ECHOメッセージ
421 他のバックアップノードにECHOメッセージを送る
422 ECHOメッセージを検証する
423 他のバックアップノードからECHOメッセージを受け取る
424 有効なECHOメッセージを判断する
426 取引要求を再構築する
428 ACCEPTメッセージを生成する
430 ACCEPTメッセージ
432 ACCEPTメッセージを生成する
434 ACCEPTメッセージ
436 取引要求を実行する
438 取引結果
500 ハッシュ木
502 取引要求
504 ECコード
506 ECメッセージ
508 ECブロック、ECブロックA
508 ECブロック、ECブロックB
508 ECブロック、ECブロックC
508 ECブロック、ECブロックD
510 葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュA
510 葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュB
510 葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュC
510 葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュD
512 非葉ノード、ハッシュ、ハッシュAB
512 非葉ノード、ハッシュ、ハッシュCD
514 非葉ノード、ルートハッシュ、ハッシュABCD
700 方法、処理
800 処理
802 バックアップノード
804 他のネットワークノード、ネットワークノード
806 エポック変更を判断する
808 個々の重みを判断する
810 加重和を判断する
812 EPOCH_CHANGEメッセージ
814 EPOCH_CHANGEメッセージを検証する
816 NEW_EPOCHメッセージ
818 NEW_EPOCHメッセージを検証する
820 有効なNEW_EPOCHメッセージを判断する
822 新しい1次ノードを判断する
1000 処理
1010 第1のフェーズ、QUERY_STATEメッセージ
1020 第2のフェーズ、REPLY_STATEメッセージ
1030 第3のフェーズ、FETCH_ECHOメッセージ
1040 第4のフェーズ、ECHOメッセージ
1050 第5のフェーズ、ローカル消去コード
1060 第6のフェーズ、ACCEPTメッセージ
1100 処理、方法
1102 ネットワークノード
1104 ネットワークノード
1106 状態要求メッセージ
1108 状態リプライメッセージ
1110 状態リプライメッセージの数を判断する
1112 対象シーケンス番号を識別する
1114 FETCH_ECHOメッセージ
1116 ECHOメッセージ
1118 ECHOメッセージを検証する
1120 有効なECHOメッセージを判断する
1122 対象取引を回復させる
1124 ACCEPTメッセージ
1300 コンセンサス装置、装置
1302 受信器、受信ユニット
1304 生成ユニット
1306 送信器、送信ユニット
1308 検証ユニット
1310 判断ユニット
1312 再構築ユニット
1314 実行ユニット
1400 コンセンサス装置、装置
1402 受信器、受信ユニット
1404 送信器、送信ユニット
1406 検証ユニット
1408 判断ユニット
1410 再構築ユニット
1412 実行ユニット
1500 1次ノード変更装置、装置
1502 判断ユニット
1504 送信器、送信ユニット
1506 受信器、受信ユニット
1508 検証ユニット
1510 動作ユニット
1600 1次ノード変更装置、装置
1602 受信器、受信ユニット
1604 検証ユニット
1606 送信器、送信ユニット
1608 判断ユニット
1700 回復装置、装置
1702 ブロードキャストユニット
1704 受信器、受信ユニット
1706 識別ユニット
1708 送信器、送信ユニット
1710 判断ユニット
1712 回復ユニット
1714 検証ユニット

Claims (30)

  1. ブロックチェーンネットワークのネットワークノードの回復処理を行うためのコンピュータで実行される方法であって、
    ブロックチェーンネットワークの複数の他のネットワークノードに状態要求メッセージを前記ブロックチェーンネットワークのネットワークノードによってブロードキャストするステップであって、前記ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ステップと、
    前記複数の他のネットワークノードから複数の状態リプライメッセージを前記ネットワークノードによって受け取るステップであって、前記複数の状態リプライメッセージのそれぞれがシーケンス番号を含む、ステップと、
    状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて前記対象シーケンス番号を前記ネットワークノードによって識別するステップであって、いくつかの前記状態リプライメッセージのそれぞれが前記同じシーケンス番号を含む、ステップと、
    前記複数の他のネットワークノードに要求メッセージを前記ネットワークノードによって送るステップであって、前記要求メッセージが、前記複数の他のネットワークノードのそれぞれからのECHOメッセージを要求し、前記ECHOメッセージが、前記対象シーケンス番号を有する前記対象取引に対する前記複数の他のネットワークノード間のコンセンサスを実現するための前記複数の他のネットワークノードのそれぞれによって送信されたメッセージであり、前記ECHOメッセージが、前記対象取引の一部、および前記複数の他のネットワークノードのそれぞれの署名を含む、ステップと、
    前記複数の他のネットワークノードから複数のECHOメッセージを前記ネットワークノードによって受け取るステップと、
    前記複数のECHOメッセージからいくつかの有効なECHOメッセージを前記ネットワークノードによって判断するステップであって、前記いくつかの有効なECHOメッセージのそれぞれが前記対象シーケンス番号を含む、ステップと、
    有効なECHOメッセージの前記数が所定の閾値を超過するとの判断に応答して、前記いくつかの有効なECHOメッセージに基づいて前記ネットワークノードにおいて前記同じシーケンス番号を有する前記対象取引を前記ネットワークノードによって回復させるステップと、
    前記ネットワークノードが回復されたことを示すメッセージを前記複数の他のネットワークノードに、前記ネットワークノードによって送るステップとを含む、
    方法。
  2. 前記複数の他のネットワークノードが、1次ノード、または1つもしくは複数のバックアップノードを含む、
    請求項1に記載の方法。
  3. 前記ネットワークノードが、1次ノードまたはバックアップノードである、
    請求項1に記載の方法。
  4. 前記要求メッセージが、前記対象シーケンス番号を含む、
    請求項1に記載の方法。
  5. 前記ネットワークノードに前記ECHOメッセージのそれぞれを送る前に、前記要求メッセージが、前記複数の他のネットワークノードのそれぞれによって検証される、
    請求項4に記載の方法。
  6. 前記方法は、
    前記ECHOメッセージのそれぞれが有効であるかどうかを前記ネットワークノードによって検証するステップをさらに含み、
    前記ECHOメッセージのそれぞれが有効であるかどうかを検証するステップが、
    マークル木を使用して前記ECHOメッセージのそれぞれが有効であるかどうかを検証するステップを含む、
    請求項1に記載の方法。
  7. 前記ECHOメッセージのそれぞれが有効であるかどうかを検証するステップが、
    前記ECHOメッセージ内の前記署名が有効であるかどうかを検証するステップをさらに含む、
    請求項6に記載の方法。
  8. 前記ECHOメッセージのそれぞれが、前記対象取引と関連付けられた複数の消去コード(EC)ブロックのうちの少なくとも1つをさらに含み、前記複数のECブロックが、前記対象取引を使用してECコードに従って生成される、
    請求項1に記載の方法。
  9. 前記いくつかの有効なECHOメッセージに基づいて前記ネットワークノードにおいて前記同じシーケンス番号を有する前記対象取引を回復させるステップが、
    前記いくつかの有効なECHOメッセージ内にある前記複数のECブロックのサブセットを使用して前記対象取引を再構築するステップを含む、
    請求項８に記載の方法。
  10. 前記ネットワークノードが回復されたことを示す前記複数の他のネットワークノードへの前記メッセージが、前記いくつかの有効なECHOメッセージ内の署名のセット、および前記対象シーケンス番号を含む、
    請求項1に記載の方法。
  11. 1つまたは複数のコンピュータに連結され、かつ以下の動作を行うように前記1つまたは複数のコンピュータによって実行可能な命令を記憶する非一時的コンピュータ可読記憶媒体であって、前記動作が、
    ブロックチェーンネットワークの複数の他のネットワークノードに状態要求メッセージを前記ブロックチェーンネットワークのネットワークノードによってブロードキャストすることであって、前記ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ことと、
    前記複数の他のネットワークノードから複数の状態リプライメッセージを前記ネットワークノードによって受け取ることであって、前記複数の状態リプライメッセージのそれぞれがシーケンス番号を含む、ことと、
    状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて前記対象シーケンス番号を前記ネットワークノードによって識別することであって、いくつかの前記状態リプライメッセージのそれぞれが前記同じシーケンス番号を含む、ことと、
    前記複数の他のネットワークノードに要求メッセージを前記ネットワークノードによって送ることであって、前記要求メッセージが、前記複数の他のネットワークノードのそれぞれからのECHOメッセージを要求し、前記ECHOメッセージが、前記対象シーケンス番号を有する前記対象取引に対する前記複数の他のネットワークノード間のコンセンサスを実現するための前記複数の他のネットワークノードのそれぞれによって送信されたメッセージであり、前記ECHOメッセージが、前記対象取引の一部、および前記複数の他のネットワークノードのそれぞれの署名を含む、ことと、
    前記複数の他のネットワークノードから複数のECHOメッセージを前記ネットワークノードによって受け取ることと、
    前記複数のECHOメッセージからいくつかの有効なECHOメッセージを前記ネットワークノードによって判断することであって、前記いくつかの有効なECHOメッセージのそれぞれが前記対象シーケンス番号を含む、ことと、
    有効なECHOメッセージの前記数が所定の閾値を超過するとの判断に応答して、前記いくつかの有効なECHOメッセージに基づいて前記ネットワークノードにおいて前記同じシーケンス番号を有する前記対象取引を前記ネットワークノードによって回復させることと、
    前記ネットワークノードが回復されたことを示すメッセージを前記複数の他のネットワークノードに、前記ネットワークノードによって送ることとを含む、
    非一時的コンピュータ可読記憶媒体。
  12. 前記複数の他のネットワークノードが、1次ノード、または1つもしくは複数のバックアップノードを含む、
    請求項11に記載の非一時的コンピュータ可読記憶媒体。
  13. 前記ネットワークノードが、1次ノードまたはバックアップノードである、
    請求項11に記載の非一時的コンピュータ可読記憶媒体。
  14. 前記要求メッセージが、前記対象シーケンス番号を含む、
    請求項11に記載の非一時的コンピュータ可読記憶媒体。
  15. 前記ネットワークノードに前記ECHOメッセージのそれぞれを送る前に、前記要求メッセージが、前記複数の他のネットワークノードのそれぞれによって検証される、
    請求項14に記載の非一時的コンピュータ可読記憶媒体。
  16. 前記非一時的コンピュータ可読記憶媒体は、前記ECHOメッセージのそれぞれが有効であるかどうかを前記ネットワークノードによって検証するように前記1つまたは複数のコンピュータによって実行可能な命令をさらに記憶し、
    前記ECHOメッセージのそれぞれが有効であるかどうかを検証することが、
    マークル木を使用して前記ECHOメッセージのそれぞれが有効であるかどうかを検証することを含む、
    請求項11に記載の非一時的コンピュータ可読記憶媒体。
  17. 前記ECHOメッセージのそれぞれが有効であるかどうかを検証することが、
    前記ECHOメッセージ内の前記署名が有効であるかどうかを検証することをさらに含む、
    請求項16に記載の非一時的コンピュータ可読記憶媒体。
  18. 前記ECHOメッセージのそれぞれが、前記対象取引と関連付けられた複数の消去コード(EC)ブロックのうちの少なくとも1つをさらに含み、
    前記複数のECブロックが、前記対象取引を使用してECコードに従って生成される、
    請求項11に記載の非一時的コンピュータ可読記憶媒体。
  19. 前記いくつかの有効なECHOメッセージに基づいて前記ネットワークノードにおいて前記同じシーケンス番号を有する前記対象取引を回復させることが、
    前記いくつかの有効なECHOメッセージ内にある前記複数のECブロックのサブセットを使用して前記対象取引を再構築することを含む、
    請求項18に記載の非一時的コンピュータ可読記憶媒体。
  20. 前記ネットワークノードが回復されたことを示す前記複数の他のネットワークノードへの前記メッセージが、前記いくつかの有効なECHOメッセージ内の署名のセット、および前記対象シーケンス番号を含む、
    請求項11に記載の非一時的コンピュータ可読記憶媒体。
  21. 1つまたは複数のコンピュータと、
    前記1つまたは複数のコンピュータに連結され、かつ以下の動作を行うように前記1つまたは複数のコンピュータによって実行可能な命令によって構成された1つまたは複数のコンピュータ可読メモリとを備えたシステムであって、前記動作が、
    ブロックチェーンネットワークの複数の他のネットワークノードに状態要求メッセージを前記ブロックチェーンネットワークのネットワークノードによってブロードキャストすることであって、前記ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ことと、
    前記複数の他のネットワークノードから複数の状態リプライメッセージを前記ネットワークノードによって受け取ることであって、前記複数の状態リプライメッセージのそれぞれがシーケンス番号を含む、ことと、
    状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて前記対象シーケンス番号を前記ネットワークノードによって識別することであって、いくつかの前記状態リプライメッセージのそれぞれが前記同じシーケンス番号を含む、ことと、
    前記複数の他のネットワークノードに要求メッセージを前記ネットワークノードによって送ることであって、前記要求メッセージが、前記複数の他のネットワークノードのそれぞれからのECHOメッセージを要求し、前記ECHOメッセージが、前記対象シーケンス番号を有する前記対象取引に対する前記複数の他のネットワークノード間のコンセンサスを実現するための前記複数の他のネットワークノードのそれぞれによって送信されたメッセージであり、前記ECHOメッセージが、前記対象取引の一部、および前記複数の他のネットワークノードのそれぞれの署名を含む、ことと、
    前記複数の他のネットワークノードから複数のECHOメッセージを前記ネットワークノードによって受け取ることと、
    前記複数のECHOメッセージからいくつかの有効なECHOメッセージを前記ネットワークノードによって判断することであって、前記いくつかの有効なECHOメッセージのそれぞれが前記対象シーケンス番号を含む、ことと、
    有効なECHOメッセージの前記数が所定の閾値を超過するとの判断に応答して、前記いくつかの有効なECHOメッセージに基づいて前記ネットワークノードにおいて前記同じシーケンス番号を有する前記対象取引を前記ネットワークノードによって回復させることと、
    前記ネットワークノードが回復されたことを示すメッセージを前記複数の他のネットワークノードに、前記ネットワークノードによって送ることとを含む、
    システム。
  22. 前記複数のネットワークノードが、1次ノード、または1つもしくは複数のバックアップノードを含む、
    請求項21に記載のシステム。
  23. 前記ネットワークノードが、1次ノードまたはバックアップノードである、
    請求項21に記載のシステム。
  24. 前記要求メッセージが、前記対象シーケンス番号を含む、
    請求項21に記載のシステム。
  25. 前記ネットワークノードに前記ECHOメッセージのそれぞれを送る前に、前記要求メッセージが、前記複数の他のネットワークノードのそれぞれによって検証される、
    請求項24に記載のシステム。
  26. 前記コンピュータ可読メモリが、前記ECHOメッセージのそれぞれが有効であるかどうかを前記ネットワークノードによって検証するように前記1つまたは複数のコンピュータによって実行可能な命令をさらに記憶し、
    前記ECHOメッセージのそれぞれが有効であるかどうかを検証することが、
    マークル木を使用して前記ECHOメッセージのそれぞれが有効であるかどうかを検証することを含む、
    請求項21に記載のシステム。
  27. 前記ECHOメッセージのそれぞれが有効であるかどうかを検証することが、
    前記ECHOメッセージ内の前記署名が有効であるかどうかを検証することをさらに含む、
    請求項26に記載のシステム。
  28. 前記ECHOメッセージのそれぞれが、前記対象取引と関連付けられた複数の消去コード(EC)ブロックのうちの少なくとも1つをさらに含み、
    前記複数のECブロックが、前記対象取引を使用してECコードに従って生成される、
    請求項21に記載のシステム。
  29. 前記いくつかの有効なECHOメッセージに基づいて前記ネットワークノードにおいて前記同じシーケンス番号を有する前記対象取引を回復させることが、
    前記いくつかの有効なECHOメッセージ内にある前記複数のECブロックのサブセットを使用して前記対象取引を再構築することを含む、
    請求項28に記載のシステム。
  30. 前記ネットワークノードが回復されたことを示す前記複数の他のネットワークノードへの前記メッセージが、前記いくつかの有効なECHOメッセージ内の署名のセット、および前記対象シーケンス番号を含む、
    請求項21に記載のシステム。
JP2019540596A 2018-12-13 2018-12-13 分散システムにおけるネットワークノードに対する回復処理の実行 Active JP6732321B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/120870 WO2019072295A2 (en) 2018-12-13 2018-12-13 EXECUTING A RECOVERY PROCESS FOR A NETWORK NODE IN A DISTRIBUTED SYSTEM

Publications (2)

Publication Number Publication Date
JP2020516105A JP2020516105A (ja) 2020-05-28
JP6732321B2 true JP6732321B2 (ja) 2020-07-29

Family

ID=66100021

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019540596A Active JP6732321B2 (ja) 2018-12-13 2018-12-13 分散システムにおけるネットワークノードに対する回復処理の実行

Country Status (15)

Country Link
US (1) US10649859B2 (ja)
EP (2) EP3560142B1 (ja)
JP (1) JP6732321B2 (ja)
KR (1) KR102157452B1 (ja)
CN (1) CN110178340B (ja)
AU (1) AU2018348335B2 (ja)
BR (1) BR112019014815A2 (ja)
CA (1) CA3050560C (ja)
ES (1) ES2818597T3 (ja)
MX (1) MX2019008741A (ja)
PH (1) PH12019501710B1 (ja)
PL (1) PL3560142T3 (ja)
RU (1) RU2718411C1 (ja)
SG (1) SG11201906535WA (ja)
WO (1) WO2019072295A2 (ja)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019072296A2 (en) 2018-12-13 2019-04-18 Alibaba Group Holding Limited REALIZING A CHANGE OF A PRIMARY NODE IN A DISTRIBUTED SYSTEM
SG11201906834SA (en) 2018-12-13 2019-08-27 Alibaba Group Holding Ltd Achieving consensus among network nodes in a distributed system
US11204933B2 (en) * 2019-05-23 2021-12-21 Advanced New Technologies Co., Ltd. Data manipulation record storage method, system, apparatus, and device
CN111095210B (zh) 2019-08-01 2023-06-30 创新先进技术有限公司 基于纠错编码存储共享的区块链数据
SG11202002912XA (en) 2019-08-01 2021-03-30 Advanced New Technologies Co Ltd Shared blockchain data storage based on error correction code
CN111033491B (zh) 2019-08-01 2023-06-30 创新先进技术有限公司 基于纠错编码存储共享的区块链数据
CN112584364B (zh) * 2019-09-30 2024-03-08 阿里巴巴集团控股有限公司 蓝牙网络及其通信方法、设备和存储介质
US20220158892A1 (en) * 2019-10-14 2022-05-19 NEC Laboratories Europe GmbH Topology-driven byzantine fault-tolerant consensus protocol with vote aggregation
CN110955721B (zh) * 2019-10-23 2022-12-06 金蝶软件（中国）有限公司 区块链节点状态维护方法、装置、计算机设备和存储介质
CN111026770B (zh) * 2019-10-29 2023-08-04 京东科技信息技术有限公司 区块链节点的账本处理方法、装置、服务器及存储介质
US11082207B2 (en) * 2019-11-13 2021-08-03 First Genesis, Inc. Blockchain platform as a service (BPaaS)
CN111274317A (zh) * 2020-01-07 2020-06-12 书生星际(北京)科技有限公司 多节点数据同步的方法和装置，以及计算机设备
WO2021175036A1 (zh) * 2020-03-06 2021-09-10 杜晓楠 在p2p网络中避免客户端节点长时间无效占用连接资源和引导客户端节点合理选择节点带宽
CN111510317B (zh) * 2020-03-06 2022-08-26 杜晓楠 弱化dbft中连续多个节点故障导致的延迟的方法、计算机可读存储介质和dbft网络
CN111355810B (zh) * 2020-03-17 2022-05-10 重庆邮电大学 一种基于信誉与投票机制的改进pbft共识方法
CN113301002B (zh) * 2020-04-24 2023-05-09 阿里巴巴集团控股有限公司 一种信息处理方法、装置、电子设备以及存储介质
CN112866374A (zh) * 2020-07-02 2021-05-28 吴春香 结合区块链支付网络的通信数据处理方法及大数据服务器
CN111526218B (zh) 2020-07-03 2020-09-22 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和系统
CN111526217B (zh) 2020-07-03 2020-10-09 支付宝(杭州)信息技术有限公司 一种区块链中的共识方法和系统
CN112422621A (zh) * 2020-09-28 2021-02-26 国网信息通信产业集团有限公司北京分公司 基于pbft区块链技术的多站融合电力数据共识方法和装置
CN113905059B (zh) * 2021-06-03 2022-07-01 电子科技大学 一种车联网的轻量型区块链的区块存储方法及模型
CN115511486A (zh) * 2021-06-07 2022-12-23 腾讯科技（深圳）有限公司 交易处理方法、装置、介质及电子设备
CN115514608B (zh) * 2021-06-22 2023-06-06 腾讯科技（深圳）有限公司 一种区块共识方法、装置、设备及存储介质
CN114584312B (zh) * 2021-10-09 2024-03-29 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN113630258B (zh) * 2021-10-09 2022-01-11 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN114020357B (zh) * 2021-11-04 2024-05-03 湖北美和易思教育科技有限公司 namenode节点的启动方法、装置、系统及介质
CN114157550B (zh) * 2021-12-06 2023-01-31 东北大学 一种基于无冲突事务合并的联盟区块链系统
CN115473908B (zh) * 2022-11-03 2023-04-28 山东区块链研究院 一种区块链节点故障恢复方法及区块链系统

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4309569A (en) 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
EP0135499B1 (en) 1983-02-09 1990-05-02 International Business Machines Corporation A method for achieving multiple processor agreement optimized for no faults
US7249259B1 (en) * 1999-09-07 2007-07-24 Certicom Corp. Hybrid signature scheme
US6671821B1 (en) 1999-11-22 2003-12-30 Massachusetts Institute Of Technology Byzantine fault tolerance
US6985956B2 (en) * 2000-11-02 2006-01-10 Sun Microsystems, Inc. Switching system
US6931431B2 (en) * 2001-01-13 2005-08-16 International Business Machines Corporation Agreement and atomic broadcast in asynchronous networks
US7502360B2 (en) 2005-03-04 2009-03-10 Itt Manufacturing Enterprises, Inc. Method and apparatus for dynamic neighbor discovery within wireless networks using time division multiple access (TDMA)
US8819102B2 (en) * 2007-07-03 2014-08-26 Cisco Technology, Inc. Method and system for managing message communications
JP5427574B2 (ja) * 2009-12-02 2014-02-26 株式会社日立製作所 仮想計算機の移動管理方法、前記移動管理方法を用いた計算機、前記移動管理方法を用いた仮想化機構および前記移動管理方法を用いた計算機システム
WO2013063330A1 (en) 2011-10-25 2013-05-02 Nicira, Inc. Chassis controllers for converting universal flows
US9471622B2 (en) * 2012-04-30 2016-10-18 International Business Machines Corporation SCM-conscious transactional key-value store
CN106462612A (zh) 2014-07-01 2017-02-22 萨思学会有限公司 用于容错通信的系统和方法
US10459805B2 (en) * 2015-04-03 2019-10-29 Oath Inc. Method and system for data recovery in a data system
US10785033B2 (en) 2015-09-04 2020-09-22 Nec Corporation Method for storing an object on a plurality of storage nodes
WO2017136527A1 (en) 2016-02-05 2017-08-10 Manifold Technology, Inc. Blockchain-enhanced database
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
WO2017186317A1 (en) 2016-10-04 2017-11-02 Nec Europe Ltd. Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
US10360191B2 (en) 2016-10-07 2019-07-23 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
US10158527B2 (en) 2016-10-28 2018-12-18 International Business Machines Corporation Changing an existing blockchain trust configuration
US10554746B2 (en) 2016-11-14 2020-02-04 International Business Machines Corporation Decentralized immutable storage blockchain configuration
US10311230B2 (en) 2016-12-24 2019-06-04 Cisco Technology, Inc. Anomaly detection in distributed ledger systems
CN106529951A (zh) 2016-12-30 2017-03-22 杭州云象网络技术有限公司 一种联盟链网络下采用异步方式的节点共识验证方法
RU2639015C1 (ru) * 2017-01-26 2017-12-19 Игорь Сан-Сенович Дю Способ контроля подлинности и качества продукции в процессе производства и реализации
CN107360206B (zh) 2017-03-29 2020-03-27 创新先进技术有限公司 一种区块链共识方法、设备及系统
US20180308091A1 (en) 2017-04-21 2018-10-25 Vmware, Inc. Fairness preserving byzantine agreements
CN107423152B (zh) * 2017-04-24 2019-05-21 杭州趣链科技有限公司 一种区块链共识节点自动恢复方法
US11626993B2 (en) * 2017-05-22 2023-04-11 Visa International Service Association Network for improved verification speed with tamper resistant data
CN107528882B (zh) 2017-07-14 2020-12-25 创新先进技术有限公司 区块链共识网络中处理共识请求的方法、装置和电子设备
WO2019055507A1 (en) 2017-09-15 2019-03-21 Identify3D, Inc. SYSTEM AND METHOD FOR MANAGING AND SECURING DATA FOR DIGITAL MANUFACTURING
US11165862B2 (en) * 2017-10-24 2021-11-02 0Chain, LLC Systems and methods of blockchain platform for distributed applications
CN108306760A (zh) 2017-12-28 2018-07-20 中国银联股份有限公司 用于在分布式系统中使管理能力自恢复的方法和装置
CN108365993B (zh) 2018-03-09 2020-04-28 深圳前海微众银行股份有限公司 区块链节点动态变更方法、系统和计算机可读存储介质
CN108616596B (zh) 2018-05-09 2020-12-25 南京邮电大学 基于动态授权和网络环境感知的区块链自适应共识方法
CN108768749B (zh) * 2018-06-21 2021-03-30 佛山科学技术学院 一种基于区块链的节点隔离自恢复方法及装置
WO2019072296A2 (en) 2018-12-13 2019-04-18 Alibaba Group Holding Limited REALIZING A CHANGE OF A PRIMARY NODE IN A DISTRIBUTED SYSTEM
SG11201906834SA (en) 2018-12-13 2019-08-27 Alibaba Group Holding Ltd Achieving consensus among network nodes in a distributed system

Also Published As

Publication number Publication date
US20190286531A1 (en) 2019-09-19
WO2019072295A3 (en) 2019-10-10
RU2718411C1 (ru) 2020-04-02
AU2018348335A1 (en) 2020-07-02
AU2018348335B2 (en) 2020-07-30
BR112019014815A2 (pt) 2020-02-27
EP3560142B1 (en) 2020-09-09
EP3560142A2 (en) 2019-10-30
KR102157452B1 (ko) 2020-09-18
EP3748906A1 (en) 2020-12-09
US10649859B2 (en) 2020-05-12
MX2019008741A (es) 2019-09-09
CA3050560A1 (en) 2019-04-18
PH12019501710A1 (en) 2020-03-09
CN110178340A (zh) 2019-08-27
EP3560142A4 (en) 2020-03-25
EP3748906B1 (en) 2021-12-01
JP2020516105A (ja) 2020-05-28
ES2818597T3 (es) 2021-04-13
SG11201906535WA (en) 2019-08-27
CA3050560C (en) 2020-06-30
CN110178340B (zh) 2021-05-18
KR20200074911A (ko) 2020-06-25
PH12019501710B1 (en) 2020-03-09
WO2019072295A2 (en) 2019-04-18
PL3560142T3 (pl) 2021-01-11

Similar Documents

Publication Publication Date Title
JP6726367B2 (ja) 分散システムにおける１次ノードの変更を行うこと
JP6732321B2 (ja) 分散システムにおけるネットワークノードに対する回復処理の実行
JP6803991B2 (ja) 分散システムにおけるネットワークノード間のコンセンサスを実現すること

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191002

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20191211

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20200403

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200413

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200522

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200608

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200702

R150 Certificate of patent or registration of utility model

Ref document number: 6732321

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250