(57)【特許請求の範囲】
【請求項１】
少なくとも１次ノードおよび１つまたは複数のバックアップノードを含むブロックチェーンネットワークの複数のネットワークノード間のコンセンサスを実現するためのコンピュータ実行方法であって、
取引要求を前記１次ノードによって受け取るステップと、
前記取引要求を使用してＥＣコードに従って複数の消去コード（ＥＣ）ブロックを前記１次ノードによって生成するステップと、
前記１つまたは複数のバックアップノードに複数の第１のメッセージを前記１次ノードによってそれぞれ送るステップであって、前記複数の第１のメッセージのそれぞれが、前記複数のＥＣブロックと関連付けられた合成ハッシュ値を含む、ステップと、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第２のメッセージを前記１次ノードによって受け取るステップであって、前記少なくとも１つの第２のメッセージが、前記複数の第１のメッセージのうちの１つ、および前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの署名を含む、ステップと、
前記バックアップノードのうちの前記少なくとも１つからの前記少なくとも１つの第２のメッセージの受領に応答して、前記少なくとも１つの第２のメッセージが有効であるかどうかを前記１次ノードによって検証するステップと、
有効な第２のメッセージの数が所定の閾値を超過するかどうかを前記１次ノードによって判断するステップと、
有効な第２のメッセージの前記数が前記所定の閾値を超過するとの判断に応答して、前記ＥＣコードに従って前記いくつかの有効な第２のメッセージのサブセットに基づいて前記取引要求を前記１次ノードによって再構築するステップと、
前記取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを前記１次ノードによって送るステップであって、前記第３のメッセージが、前記有効な第２のメッセージ内にある署名のセットを含む、ステップと、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを前記１次ノードによって受け取るステップと、
同一である所定の数の第３のメッセージの受領に応答して、前記取引要求を前記１次ノードによって実行するステップと
を含む、方法。
【請求項２】
前記取引要求が、シーケンス番号と関連付けられる、請求項１に記載の方法。
【請求項３】
ＥＣコードに従って前記複数のＥＣブロックを生成する前記ステップが、
前記ＥＣコードを使用して前記取引要求をＥＣメッセージに変換するステップと、
前記ＥＣメッセージを前記複数のＥＣブロックに分割するステップと
を含む、請求項１に記載の方法。
【請求項４】
前記複数のＥＣブロックの前記合成ハッシュ値が、ハッシュ木を使用して生成される、請求項１に記載の方法。
【請求項５】
前記ハッシュ木がマークル木を含み、前記合成ハッシュ値が前記マークル木のルートハッシュ値である、請求項４に記載の方法。
【請求項６】
前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの前記署名が、前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの秘密鍵署名を含む、請求項１に記載の方法。
【請求項７】
前記少なくとも１つの第２のメッセージが、前記複数のＥＣブロックのうちの少なくとも１つをさらに含む、請求項１に記載の方法。
【請求項８】
前記少なくとも１つの第２のメッセージが有効であるかどうかを前記１次ノードによって検証する前記ステップが、
前記少なくとも１つの第２のメッセージ内の前記複数のＥＣブロックのうちの前記少なくとも１つを使用して、再構築されたハッシュ木を前記１次ノードによって生成するステップと、
前記再構築されたハッシュ木の再構築された合成ハッシュ値を前記１次ノードによって判断するステップと、
前記再構築された合成ハッシュ値を前記少なくとも１つの第２のメッセージ内の合成ハッシュ値と前記１次ノードによって比較するステップと、
前記再構築された合成ハッシュ値が前記少なくとも１つの第２のメッセージ内の前記合成ハッシュ値にマッチするかどうかを前記１次ノードによって判断するステップと
を含む、請求項７に記載の方法。
【請求項９】
前記再構築された合成ハッシュ値が前記第２のメッセージ内の前記合成ハッシュ値にマッチするとの判断に応答して、前記少なくとも１つの第２のメッセージが有効であると前記１次ノードによって判断するステップ
をさらに含む、請求項７に記載の方法。
【請求項１０】
同一である前記所定の数の第３のメッセージが、署名の同一セットを有する前記所定の数の前記第３のメッセージを含む、請求項１に記載の方法。
【請求項１１】
少なくとも１次ノードおよび１つまたは複数のバックアップノードを含むブロックチェーンの複数のネットワークノード間のコンセンサスを実現するためのコンピュータ実行方法であって、
前記１次ノードから第１のメッセージをバックアップノードによって受け取るステップであって、前記第１のメッセージが、複数のＥＣブロックと関連付けられた合成ハッシュ値を含み、前記複数のＥＣブロックが、取引要求を使用してＥＣコードに従って前記１次ノードによって生成される、ステップと、
前記第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージを前記バックアップノードによって送るステップであって、前記第２のメッセージが、前記第１のメッセージおよび前記第１のメッセージと関連付けられた前記バックアップノードの署名を含む、ステップと、
前記バックアップノードによって、前記バックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取るステップと、
前記少なくとも１つのバックアップノードからの前記少なくとも１つの第２のメッセージの受領に応答して、前記少なくとも１つの第２のメッセージが有効であるかどうかを前記バックアップノードによって検証するステップと、
有効な第２のメッセージの数が所定の閾値を超過するかどうかを前記バックアップノードによって判断するステップと、
有効な第２のメッセージの前記数が前記所定の閾値を超過するとの判断に応答して、前記ＥＣコードに従って前記いくつかの有効な第２のメッセージのサブセットに基づいて前記取引要求を前記バックアップノードによって再構築するステップと、
前記取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを前記バックアップノードによって送るステップであって、前記第３のメッセージが、前記有効な第２のメッセージ内にある署名のセットを含む、ステップと、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを前記バックアップノードによって受け取るステップと、
同一である所定の数の第３のメッセージの受領に応答して、前記取引要求を前記バックアップノードによって実行するステップと
を含む、方法。
【請求項１２】
ＥＣコードに従って前記複数のＥＣブロックを生成する前記ステップが、
前記ＥＣコードを使用して前記取引要求をＥＣメッセージに変換するステップと、
前記ＥＣメッセージを前記複数のＥＣブロックに分割するステップと
を含む、請求項１１に記載の方法。
【請求項１３】
前記複数のＥＣブロックの前記合成ハッシュ値が、ハッシュ木を使用して生成される、請求項１１に記載の方法。
【請求項１４】
前記ハッシュ木がマークル木を含み、前記合成ハッシュ値が前記マークル木のルートハッシュ値である、請求項１３に記載の方法。
【請求項１５】
前記第１のメッセージと関連付けられた前記バックアップノードの前記署名が、前記第１のメッセージと関連付けられた前記バックアップノードの秘密鍵署名を含む、請求項１１に記載の方法。
【請求項１６】
前記少なくとも１つの第２のメッセージが、前記複数のＥＣブロックのうちの少なくとも１つをさらに含む、請求項１１に記載の方法。
【請求項１７】
前記少なくとも１つの第２のメッセージが有効であるかどうかを前記バックアップノードによって検証する前記ステップが、
前記少なくとも１つの第２のメッセージ内の前記複数のＥＣブロックのうちの前記少なくとも１つを使用して、再構築されたハッシュ木を前記バックアップノードによって生成するステップと、
前記再構築されたハッシュ木の再構築された合成ハッシュ値を前記バックアップノードによって判断するステップと、
前記バックアップノードによって、前記再構築された合成ハッシュ値を前記少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較するステップと、
前記再構築された合成ハッシュ値が前記少なくとも１つの第２のメッセージ内の前記合成ハッシュ値にマッチするかどうかを前記バックアップノードによって判断するステップと
を含む、請求項１６に記載の方法。
【請求項１８】
前記再構築された合成ハッシュ値が前記第２のメッセージ内の前記合成ハッシュ値にマッチするとの判断に応答して、前記少なくとも１つの第２のメッセージが有効であると前記バックアップノードによって判断するステップ
をさらに含む、請求項１７に記載の方法。
【請求項１９】
同一である前記所定の数の第３のメッセージが、署名の同一セットを有する前記所定の数の前記第３のメッセージを含む、請求項１１に記載の方法。
【請求項２０】
１つまたは複数のコンピュータに連結され、
ブロックチェーンネットワークの１次ノードによって取引要求を受け取ることであって、前記ブロックチェーンネットワークが、１つまたは複数のバックアップノードをさらに含む、受け取ることと、
前記取引要求を使用してＥＣコードに従って複数の消去コード（ＥＣ）ブロックを前記１次ノードによって生成することと、
前記１つまたは複数のバックアップノードに複数の第１のメッセージを前記１次ノードによってそれぞれ送ることであって、前記複数の第１のメッセージのそれぞれが、前記複数のＥＣブロックと関連付けられた合成ハッシュ値を含む、送ることと、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第２のメッセージを前記１次ノードによって受け取ることであって、前記少なくとも１つの第２のメッセージが、前記複数の第１のメッセージのうちの１つ、および前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの署名を含む、受け取ることと、
前記バックアップノードのうちの前記少なくとも１つからの前記少なくとも１つの第２のメッセージの受領に応答して、前記少なくとも１つの第２のメッセージが有効であるかどうかを前記１次ノードによって検証することと、
有効な第２のメッセージの数が所定の閾値を超過するかどうかを前記１次ノードによって判断することと、
有効な第２のメッセージの前記数が前記所定の閾値を超過するとの判断に応答して、前記ＥＣコードに従って前記いくつかの有効な第２のメッセージのサブセットに基づいて前記取引要求を前記１次ノードによって再構築することと、
前記取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを前記１次ノードによって送ることであって、前記第３のメッセージが、前記有効な第２のメッセージ内にある署名のセットを含む、送ることと、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを前記１次ノードによって受け取ることと、
同一である所定の数の第３のメッセージの受領に応答して、前記取引要求を前記１次ノードによって実行することと
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によって構成された、非一時的コンピュータ可読ストレージ媒体。
【請求項２１】
前記取引要求が、シーケンス番号と関連付けられる、請求項２０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２２】
ＥＣコードに従って前記複数のＥＣブロックを前記生成することが、
前記ＥＣコードを使用して前記取引要求をＥＣメッセージに変換することと、
前記ＥＣメッセージを前記複数のＥＣブロックに分割することと
を含む、請求項２０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２３】
前記複数のＥＣブロックの前記合成ハッシュ値が、ハッシュ木を使用して生成される、請求項２０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２４】
前記ハッシュ木がマークル木を含み、前記合成ハッシュ値が前記マークル木のルートハッシュ値である、請求項２３に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２５】
前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの前記署名が、前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの秘密鍵署名を含む、請求項２０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２６】
前記少なくとも１つの第２のメッセージが、前記複数のＥＣブロックのうちの少なくとも１つをさらに含む、請求項２０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２７】
前記少なくとも１つの第２のメッセージが有効であるかどうかを前記１次ノードによって前記検証することが、
前記少なくとも１つの第２のメッセージ内の前記複数のＥＣブロックのうちの前記少なくとも１つを使用して、再構築されたハッシュ木を前記１次ノードによって生成することと、
前記再構築されたハッシュ木の再構築された合成ハッシュ値を前記１次ノードによって判断することと、
前記１次ノードによって、前記再構築された合成ハッシュ値を前記少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、
前記再構築された合成ハッシュ値が前記少なくとも１つの第２のメッセージ内の前記合成ハッシュ値にマッチするかどうかを前記１次ノードによって判断することと
を含む、請求項２６に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２８】
前記再構築された合成ハッシュ値が前記第２のメッセージ内の前記合成ハッシュ値にマッチするとの判断に応答して、前記少なくとも１つの第２のメッセージが有効であると前記１次ノードによって判断すること
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によってさらに構成された、請求項２７に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項２９】
同一である前記所定の数の第３のメッセージが、署名の同一セットを有する前記所定の数の前記第３のメッセージを含む、請求項２０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項３０】
１つまたは複数のコンピュータと、
前記１つまたは複数のコンピュータに連結され、
ブロックチェーンネットワークの１次ノードによって取引要求を受け取ることであって、前記ブロックチェーンネットワークが、１つまたは複数のバックアップノードをさらに含む、受け取ること、
前記取引要求を使用してＥＣコードに従って複数の消去コード（ＥＣ）ブロックを前記１次ノードによって生成すること、
前記１つまたは複数のバックアップノードに複数の第１のメッセージを前記１次ノードによってそれぞれ送ることであって、前記複数の第１のメッセージのそれぞれが、前記複数のＥＣブロックと関連付けられた合成ハッシュ値を含む、送ること、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第２のメッセージを前記１次ノードによって受け取ることであって、前記少なくとも１つの第２のメッセージが、前記複数の第１のメッセージのうちの１つ、および前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの署名を含む、受け取ること、
前記バックアップノードのうちの前記少なくとも１つからの前記少なくとも１つの第２のメッセージの受領に応答して、前記少なくとも１つの第２のメッセージが有効であるかどうかを前記１次ノードによって検証すること、
有効な第２のメッセージの数が所定の閾値を超過するかどうかを前記１次ノードによって判断すること、
有効な第２のメッセージの前記数が前記所定の閾値を超過するとの判断に応答して、前記ＥＣコードに従って前記いくつかの有効な第２のメッセージのサブセットに基づいて前記取引要求を前記１次ノードによって再構築すること、
前記取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを前記１次ノードによって送ることであって、前記第３のメッセージが、前記有効な第２のメッセージ内にある署名のセットを含む、送ること、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを前記１次ノードによって受け取ること、ならびに
同一である所定の数の第３のメッセージの受領に応答して、前記取引要求を前記１次ノードによって実行すること
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によって構成された１つまたは複数のコンピュータ可読メモリと
を含む、システム。
【請求項３１】
前記取引要求が、シーケンス番号と関連付けられる、請求項３０に記載のシステム。
【請求項３２】
ＥＣコードに従って前記複数のＥＣブロックを前記生成することが、
前記ＥＣコードを使用して前記取引要求をＥＣメッセージに変換することと、
前記ＥＣメッセージを前記複数のＥＣブロックに分割することと
を含む、請求項３０に記載のシステム。
【請求項３３】
前記複数のＥＣブロックの前記合成ハッシュ値が、ハッシュ木を使用して生成される、請求項３０に記載のシステム。
【請求項３４】
前記ハッシュ木がマークル木を含み、前記合成ハッシュ値が前記マークル木のルートハッシュ値である、請求項３３に記載のシステム。
【請求項３５】
前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの前記署名が、前記複数の第１のメッセージのうちの前記１つと関連付けられた前記バックアップノードのうちの前記少なくとも１つの秘密鍵署名を含む、請求項３０に記載のシステム。
【請求項３６】
前記少なくとも１つの第２のメッセージが、前記複数のＥＣブロックのうちの少なくとも１つをさらに含む、請求項３０に記載のシステム。
【請求項３７】
前記少なくとも１つの第２のメッセージが有効であるかどうかを前記１次ノードによって前記検証することが、
前記少なくとも１つの第２のメッセージ内の前記複数のＥＣブロックのうちの前記少なくとも１つを使用して、再構築されたハッシュ木を前記１次ノードによって生成することと、
前記再構築されたハッシュ木の再構築された合成ハッシュ値を前記１次ノードによって判断することと、
前記１次ノードによって、前記再構築された合成ハッシュ値を前記少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、
前記再構築された合成ハッシュ値が前記少なくとも１つの第２のメッセージ内の前記合成ハッシュ値にマッチするかどうかを前記１次ノードによって判断することと
を含む、請求項３６に記載のシステム。
【請求項３８】
前記コンピュータメモリが、
前記再構築された合成ハッシュ値が前記第２のメッセージ内の前記合成ハッシュ値にマッチするとの判断に応答して、前記少なくとも１つの第２のメッセージが有効であると前記１次ノードによって判断すること
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によってさらに構成された、請求項３７に記載のシステム。
【請求項３９】
同一である前記所定の数の第３のメッセージが、署名の同一セットを有する前記所定の数の前記第３のメッセージを含む、請求項３０に記載のシステム。
【請求項４０】
１つまたは複数のコンピュータに連結され、
ブロックチェーンネットワークの１次ノードから第１のメッセージを前記ブロックチェーンネットワークのバックアップノードによって受け取ることであって、前記第１のメッセージが、複数のＥＣブロックと関連付けられた合成ハッシュ値を含み、前記複数のＥＣブロックが、取引要求を使用してＥＣコードに従って前記１次ノードによって生成される、受け取ることと、
前記第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージを前記バックアップノードによって送ることであって、前記第２のメッセージが、前記第１のメッセージおよび前記第１のメッセージと関連付けられた前記バックアップノードの署名を含む、送ることと、
前記バックアップノードによって前記バックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取ることと、
前記少なくとも１つのバックアップノードからの前記少なくとも１つの第２のメッセージの受領に応答して、前記少なくとも１つの第２のメッセージが有効であるかどうかを前記バックアップノードによって検証することと、
有効な第２のメッセージの数が所定の閾値を超過するかどうかを前記バックアップノードによって判断することと、
有効な第２のメッセージの前記数が所定の閾値を超過するとの判断に応答して、前記ＥＣコードに従って前記いくつかの有効な第２のメッセージのサブセットに基づいて前記取引要求を前記バックアップノードによって再構築することと、
前記取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを前記バックアップノードによって送ることであって、前記第３のメッセージが、前記有効な第２のメッセージ内にある署名のセットを含む、送ることと、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを前記バックアップノードによって受け取ることと、
同一である所定の数の第３のメッセージの受領に応答して、前記取引要求を前記バックアップノードによって実行することと
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によって構成された、非一時的コンピュータ可読ストレージ媒体。
【請求項４１】
ＥＣコードに従って前記複数のＥＣブロックを前記生成することが、
前記ＥＣコードを使用して前記取引要求をＥＣメッセージに変換することと、
前記ＥＣメッセージを前記複数のＥＣブロックに分割することと
を含む、請求項４０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４２】
前記複数のＥＣブロックの前記合成ハッシュ値が、ハッシュ木を使用して生成される、請求項４０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４３】
前記ハッシュ木がマークル木を含み、前記合成ハッシュ値が前記マークル木のルートハッシュ値である、請求項４２に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４４】
前記第１のメッセージと関連付けられた前記バックアップノードの前記署名が、前記第１のメッセージと関連付けられた前記バックアップノードの秘密鍵署名を含む、請求項４０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４５】
前記少なくとも１つの第２のメッセージが、前記複数のＥＣブロックのうちの少なくとも１つをさらに含む、請求項４０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４６】
前記少なくとも１つの第２のメッセージが有効であるかどうかを前記バックアップノードによって前記検証することが、
前記少なくとも１つの第２のメッセージ内の前記複数のＥＣブロックのうちの前記少なくとも１つを使用して、再構築されたハッシュ木を前記バックアップノードによって生成することと、
前記再構築されたハッシュ木の再構築された合成ハッシュ値を前記バックアップノードによって判断することと、
前記バックアップノードによって、前記再構築された合成ハッシュ値を前記少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、
前記再構築された合成ハッシュ値が前記少なくとも１つの第２のメッセージ内の前記合成ハッシュ値にマッチするかどうかを前記バックアップノードによって判断することと
を含む、請求項４５に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４７】
前記再構築された合成ハッシュ値が前記第２のメッセージ内の前記合成ハッシュ値にマッチするとの判断に応答して、前記少なくとも１つの第２のメッセージが有効であると前記バックアップノードによって判断すること
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によってさらに構成された、請求項４６に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４８】
同一である前記所定の数の第３のメッセージが、署名の同一セットを有する前記所定の数の前記第３のメッセージを含む、請求項４０に記載の非一時的コンピュータ可読ストレージ媒体。
【請求項４９】
１つまたは複数のコンピュータと、
前記１つまたは複数のコンピュータに連結され、
ブロックチェーンネットワークの１次ノードから第１のメッセージを前記ブロックチェーンネットワークのバックアップノードによって受け取ることであって、前記第１のメッセージが、複数のＥＣブロックと関連付けられた合成ハッシュ値を含み、前記複数のＥＣブロックが、取引要求を使用してＥＣコードに従って前記１次ノードによって生成される、受け取ること、
前記第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージを前記バックアップノードによって送ることであって、前記第２のメッセージが、前記第１のメッセージおよび前記第１のメッセージと関連付けられた前記バックアップノードの署名を含む、送ること、
前記バックアップノードによって前記バックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取ること、
前記少なくとも１つのバックアップノードからの前記少なくとも１つの第２のメッセージの受領に応答して、前記少なくとも１つの第２のメッセージが有効であるかどうかを前記バックアップノードによって検証すること、
有効な第２のメッセージの数が所定の閾値を超過するかどうかを前記バックアップノードによって判断すること、
有効な第２のメッセージの前記数が前記所定の閾値を超過するとの判断に応答して、前記ＥＣコードに従って前記いくつかの有効な第２のメッセージのサブセットに基づいて前記取引要求を前記バックアップノードによって再構築すること、
前記取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを前記バックアップノードによって送ることであって、前記第３のメッセージが、前記有効な第２のメッセージ内にある署名のセットを含む、送ること、
前記バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを前記バックアップノードによって受け取ること、ならびに
同一である所定の数の第３のメッセージの受領に応答して、前記取引要求を前記バックアップノードによって実行すること
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によって構成された１つまたは複数のコンピュータ可読メモリと
を含む、システム。
【請求項５０】
ＥＣコードに従って前記複数のＥＣブロックを前記生成することが、
前記ＥＣコードを使用して前記取引要求をＥＣメッセージに変換することと、
前記ＥＣメッセージを前記複数のＥＣブロックに分割することと
を含む、請求項４９に記載のシステム。
【請求項５１】
前記複数のＥＣブロックの前記合成ハッシュ値が、ハッシュ木を使用して生成される、請求項４９に記載のシステム。
【請求項５２】
前記ハッシュ木がマークル木を含み、前記合成ハッシュ値が前記マークル木のルートハッシュ値である、請求項５１に記載のシステム。
【請求項５３】
前記第１のメッセージと関連付けられた前記バックアップノードの前記署名が、前記第１のメッセージと関連付けられた前記バックアップノードの秘密鍵署名を含む、請求項４９に記載のシステム。
【請求項５４】
前記少なくとも１つの第２のメッセージが、前記複数のＥＣブロックのうちの少なくとも１つをさらに含む、請求項４９に記載のシステム。
【請求項５５】
前記少なくとも１つの第２のメッセージが有効であるかどうかを前記バックアップノードによって前記検証することが、
前記少なくとも１つの第２のメッセージ内の前記複数のＥＣブロックのうちの前記少なくとも１つを使用して、再構築されたハッシュ木を前記バックアップノードによって生成することと、
前記再構築されたハッシュ木の再構築された合成ハッシュ値を前記バックアップノードによって判断することと、
前記バックアップノードによって、前記再構築された合成ハッシュ値を前記少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、
前記再構築された合成ハッシュ値が前記少なくとも１つの第２のメッセージ内の前記合成ハッシュ値にマッチするかどうかを前記バックアップノードによって判断することと
を含む、請求項５４に記載のシステム。
【請求項５６】
前記コンピュータメモリが、
前記再構築された合成ハッシュ値が前記第２のメッセージ内の前記合成ハッシュ値にマッチするとの判断に応答して、前記少なくとも１つの第２のメッセージが有効であると前記バックアップノードによって判断すること
を行うように前記１つまたは複数のコンピュータによって実行可能な命令によってさらに構成された、請求項５５に記載のシステム。
【請求項５７】
同一である前記所定の数の第３のメッセージが、署名の同一セットを有する前記所定の数の前記第３のメッセージを含む、請求項４９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
分散台帳システム（ＤＬＳ：  Ｄｉｓｔｒｉｂｕｔｅｄ  ｌｅｄｇｅｒ  ｓｙｓｔｅｍ）は、コンセンサスネットワークおよび／またはブロックチェーンネットワークと呼ばれることも可能であり、参加エンティティが安全かつ不変にデータを格納することを可能にする。ＤＬＳは、一般に、いずれかの特定のユーザ事例を参照することなく、ブロックチェーンネットワークと呼ばれる。ブロックチェーンネットワークの例は、公開ブロックチェーンネットワーク、プライベートブロックチェーンネットワーク、およびコンソーシアムブロックチェーンネットワークを含むことができる。公開ブロックチェーンネットワークは、全てのエンティティがＤＬＳを使用してコンセンサス処理に参加することに対して開かれている。プライベートブロックチェーンネットワークは、読み書き許可を中心に制御する特定のエンティティに提供される。コンソーシアムブロックチェーンネットワークは、コンセンサス処理を制御するエンティティの選択グループに提供され、アクセス制御層を含む。
【０００２】
コンセンサスメカニズムは、分散ブロックチェーンシステムの主要な構成要素である。コンセンサスメカニズムは、分散処理またはシステムの間の単一データ値に対する合意を実現するために使用されるコンピュータサイエンスにおける処理である。コンセンサスメカニズムは、複数の信頼できないノードを含むネットワークにおける信頼性を実現するように設計される。コンセンサス問題として知られるこの問題を解決することは、分散コンピューティングおよびマルチエージェントシステムにおいて重要である。
【０００３】
ブロックチェーンは、ノード間の合意に達するためのコンセンサスメカニズムに依存する。ブロックチェーンは、ピアツーピア（Ｐ２Ｐ）ネットワーク上の分散コンピュータによって管理される非集中型データベースである。各ピアは、単一障害点（ＳＰＯＦ）を防ぐために台帳のコピーを維持する。更新および有効化は、全てのコピーに同時に反映される。
【０００４】
ブロックチェーンシステムのネットワークノード間のコンセンサスを行うために、いくつかの既存の技法が使用されることが可能であるが、コンセンサスを行うためのより効率的な解決策が有利になるであろう。
【発明の概要】
【課題を解決するための手段】
【０００５】
本明細書の実装形態は、分散システム（例えばブロックチェーンネットワーク）におけるコンセンサス問題に対処するためのコンピュータ実行方法を含む。より詳細には、本明細書の実装形態は、分散システムにおけるネットワークノード間のコンセンサスを実現することを対象とする。
【０００６】
いくつかの実装形態において、アクションは、ブロックチェーンネットワークの１次ノードによって取引要求を受け取ることと、取引要求を使用して１次ノードによってＥＣコードに従っていくつかの消去コード（ＥＣ：  ｅｒａｓｕｒｅ  ｃｏｄｅ）ブロックを生成することと、１次ノードによってブロックチェーンネットワークの１つまたは複数のバックアップノードにいくつかの第１のメッセージを送ることであって、いくつかの第１のメッセージのそれぞれが、いくつかのＥＣブロックと関連付けられた合成ハッシュ値を含む、送ることと、バックアップノードのうちの少なくとも１つから１次ノードによって少なくとも１つの第２のメッセージを受け取ることであって、少なくとも１つの第２のメッセージが、いくつかの第１のメッセージのうちの１つ、およびいくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名を含む、受け取ることと、バックアップノードのうちの少なくとも１つからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかを１次ノードによって検証することと、有効な第２のメッセージの数が所定の閾値を超過するかどうかを１次ノードによって判断することと、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて１次ノードによって取引要求を再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、１次ノードによって他のネットワークノードに第３のメッセージを送ることであって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも１つから１次ノードによって少なくとも１つの第３のメッセージを受け取ることと、同一である所定の数の第３のメッセージの受領に応答して、１次ノードによって取引要求を実行することと、を含む。
【０００７】
他の実装形態は、コンピュータストレージデバイス上でエンコードされた方法のアクションを行うように構成された、対応するシステム、装置、およびコンピュータプログラムを含む。
【０００８】
これらおよび他の実装形態は、それぞれ任意選択で、以下の特徴の１つまたは複数を含む。
【０００９】
以下の特徴のいずれかと組み合わせ可能であり、取引要求がシーケンス番号と関連付けられる、第１の特徴。
【００１０】
以下の特徴のいずれかと組み合わせ可能であり、ＥＣコードを使用して取引要求をＥＣメッセージに変換することと、いくつかのＥＣブロックにＥＣメッセージを分割することと、を１次ノードが行う、第２の特徴。
【００１１】
以下の特徴のいずれかと組み合わせ可能であり、いくつかのＥＣブロックの合成ハッシュ値がハッシュ木を使用して生成される、第３の特徴。
【００１２】
以下の特徴のいずれかと組み合わせ可能であり、ハッシュ木がマークル木を含む、第４の特徴。
【００１３】
以下の特徴のいずれかと組み合わせ可能であり、合成ハッシュ値がマークル木のルートハッシュ値である、第５の特徴。
【００１４】
以下の特徴のいずれかと組み合わせ可能であり、いくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名が、いくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの秘密鍵署名を含む、第６の特徴。
【００１５】
以下の特徴のいずれかと組み合わせ可能であり、少なくとも１つの第２のメッセージが、いくつかのＥＣブロックのうちの少なくとも１つをさらに含む、第７の特徴。
【００１６】
以下の特徴のいずれかと組み合わせ可能であり、少なくとも１つの第２のメッセージ内のいくつかのＥＣブロックのうちの少なくとも１つを使用して、再構築されたハッシュ木をさらに生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値を少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、再構築された合成ハッシュ値が少なくとも１つの第２のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を１次ノードが行う、第８の特徴。
【００１７】
以下の特徴のいずれかと組み合わせ可能であり、再構築された合成ハッシュ値が第２のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも１つの第２のメッセージが有効であると１次ノードがさらに判断する、第９の特徴。
【００１８】
以下の特徴のいずれかと組み合わせ可能であり、同一である所定の数の第３のメッセージが、署名の同一セットを有する所定の数の第３のメッセージを含む、第１０の特徴。
【００１９】
いくつかの実装形態において、アクションは、１次ノードから第１のメッセージをバックアップノードによって受け取ることであって、第１のメッセージが、複数のＥＣブロックと関連付けられた合成ハッシュ値を含み、複数のＥＣブロックが、取引要求を使用してＥＣコードに従って１次ノードによって生成される、受け取ることと、第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージをバックアップノードによって送ることであって、第２のメッセージが、第１のメッセージおよび第１のメッセージと関連付けられたバックアップノードの署名を含む、送ることと、このバックアップノードによってこのバックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取ることと、少なくとも１つのバックアップノードからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかをバックアップノードによって検証することと、有効な第２のメッセージの数が所定の閾値を超過するかどうかをバックアップノードによって判断することと、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて取引要求をバックアップノードによって再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージをバックアップノードによって送ることであって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージをバックアップノードによって受け取ることと、同一である所定の数の第３のメッセージの受領に応答して、取引要求をバックアップノードによって実行することと、を含む。
【００２０】
他の実装形態は、コンピュータストレージデバイス上でエンコードされた方法のアクションを行うように構成された、対応するシステム、装置、およびコンピュータプログラムを含む。
【００２１】
これらおよび他の実装形態は、それぞれ任意選択で、以下の特徴の１つまたは複数を含むことができる。
【００２２】
以下の特徴のいずれかと組み合わせ可能であり、ＥＣコードに従って複数のＥＣブロックを生成することが、ＥＣメッセージを複数のＥＣブロックに分割するＥＣコードを使用して取引要求をＥＣメッセージに変換することを含む、第１の特徴。
【００２３】
以下の特徴のいずれかと組み合わせ可能であり、複数のＥＣブロックの合成ハッシュ値が、ハッシュ木を使用して生成される、第２の特徴。
【００２４】
以下の特徴のいずれかと組み合わせ可能であり、ハッシュ木がマークル木を含み、合成ハッシュ値がマークル木のルートハッシュ値である、第３の特徴。
【００２５】
以下の特徴のいずれかと組み合わせ可能であり、第１のメッセージと関連付けられたバックアップノードの署名が、第１のメッセージと関連付けられたバックアップノードの秘密鍵署名を含む、第４の特徴。
【００２６】
以下の特徴のいずれかと組み合わせ可能であり、少なくとも１つの第２のメッセージが、複数のＥＣブロックのうちの少なくとも１つをさらに含む、第５の特徴。
【００２７】
以下の特徴のいずれかと組み合わせ可能であり、少なくとも１つの第２のメッセージが有効であるかどうかをバックアップノードによって検証することが、少なくとも１つの第２のメッセージ内の複数のＥＣブロックのうちの少なくとも１つを使用して、再構築されたハッシュ木をバックアップノードによって生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値をバックアップノードによって判断することと、再構築された合成ハッシュ値を少なくとも１つの第２のメッセージ内の合成ハッシュ値とバックアップノードによって比較することと、再構築された合成ハッシュ値が少なくとも１つの第２のメッセージ内の合成ハッシュ値にマッチするかどうかをバックアップノードによって判断することと、を含む、第７の特徴。
【００２８】
以下の特徴のいずれかと組み合わせ可能であり、再構築された合成ハッシュ値が第２のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも１つの第２のメッセージが有効であるとバックアップノードによって判断することをさらに含む、第８の特徴。
【００２９】
以下の特徴のいずれかと組み合わせ可能であり、同一である所定の数の第３のメッセージが、署名の同一セットを有する所定の数の第３のメッセージを含む、第９の特徴。
【００３０】
本明細書は、１つまたは複数のプロセッサに連結され、１つまたは複数のプロセッサによって実行されると、本明細書で提供される方法の実装形態による動作を１つまたは複数のプロセッサに行わせる、１つまたは複数の非一時的コンピュータ可読ストレージ媒体に格納された命令を有する、１つまたは複数の非一時的コンピュータ可読ストレージ媒体も提供する。
【００３１】
本明細書は、本明細書で提供される方法を実行するためのシステムをさらに提供する。システムは、１つまたは複数のプロセッサと、１つまたは複数のプロセッサによって実行されると、本明細書で提供される方法の実装形態による動作を１つまたは複数のプロセッサに行わせる、コンピュータ可読ストレージ媒体に格納された命令を有する、１つまたは複数のプロセッサに連結されたコンピュータ可読ストレージ媒体と、を含む。
【００３２】
本明細書は、分散システムにおけるネットワークノード間のコンセンサスを実現するため、分散システムにおける１次ノードの変更を行うため、および分散システムにおけるネットワークノードに対する回復処理を行うため、の技法を含む改良されたコンセンサスメカニズムを開示する。説明されるコンセンサスメカニズムは、様々な用途において様々な長所を実現することができる。
【００３３】
例えば、下記で論じられるようなコンセンサス処理は、ブロックチェーンシステムの動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、説明されるコンセンサス処理は、ＥＣコードに従って取引要求をいくつかの消去コード（ＥＣ）ブロックにコンバートすること、およびネットワークノードのそれぞれにＥＣブロックのうちの１つを送ること、を含む。ＥＣブロックは、元の取引要求よりサイズが小さい。したがって、完全な取引要求の代わりにＥＣブロックをネットワークノードに送ることは、ブロックチェーンネットワークのネットワークノード間で送信されるデータブロックのサイズを低減させ、このことにより、ネットワーク帯域幅を節約し、ネットワーク負荷を低減させる。これは、ネットワークノードのメモリ空間との間で読み書きされるデータのサイズをさらに低減させ、このことにより、ネットワークノードのメモリ空間に対する負担を低減させ、全体的なブロックチェーンシステムの効率性を改善する。
【００３４】
さらに、本明細書は、コンセンサス処理の複数のフェーズに個々の重みを割り当てること、複数のフェーズの個々の重みに基づいて加重和を判断すること、および加重和に基づいて新しい１次ノードを判断することを含むエポック変更処理を説明する。ラウンドロビン方法の代わりの加重和に基づくエポック変更処理は、故障していない新しい１次ノードをタイムリに選ぶことを容易にすることができる。ラウンドロビン方法とは異なり、本明細書におけるエポック変更処理は、加重和に応じて新しい１次ノードを選択し、これは、故障していない新しい１次ノードを見つける際のレイテンシまたは遅延を低減させることができる。これは、ブロックチェーンサービスを提供する際に全体的なブロックチェーンシステムの効率性をさらに改善することができる。
【００３５】
さらに、本明細書は、新しい１次ノードとして使用されるネットワークノードによって状態要求メッセージを送ること、および他のネットワークノードから状態リプライメッセージを受け取ることなどの動作を含む回復処理を論じる。これらの動作は、故障しているネットワークノードの回復処理が、他の故障していないネットワークノード間のコンセンサス処理の正常動作に支障を来さないように行われる。これは、回復処理の複雑性を低減させることによって、故障しているネットワークノードを回復させるためのコンピューティングリソースおよびネットワークリソースを節約することを容易にする。
【００３６】
本明細書による方法は、本明細書で説明される態様および特徴の任意の組合せを含むことができるということが認知される。すなわち、本明細書による方法は、本明細書で具体的に説明される態様および特徴の組合せに限定されるのではなく、提供される態様および特徴の任意の組合せも含む。
【００３７】
本明細書の１つまたは複数の実装形態の詳細が、添付の図面および下記の説明において示される。本明細書の他の特徴および長所は、説明および図面から、また特許請求の範囲から明らかになるであろう。
【図面の簡単な説明】
【００３８】
【図１】本明細書の実装形態を実行するために使用されることが可能な環境の例を描写する図である。
【図２】本明細書の実装形態による概念アーキテクチャの例を描写する図である。
【図３】本明細書の実装形態に従って実行されることが可能なコンセンサス処理の例を描写する図である。
【図４】本明細書の実装形態に従って実行されることが可能なコンセンサス処理の例を描写する図である。
【図５】本明細書の実装形態によるハッシュ木の例を描写する図である。
【図６】本明細書の実装形態による分散システムのネットワークノード間で通信されるメッセージの例を描写する図である。
【図７】本明細書の実装形態による分散システムにおける１次ノードの変更を行う処理の例を描写する図である。
【図８】本明細書の実装形態による分散システムにおける１次ノードの変更を行う処理の例を描写する図である。
【図９】本明細書の実装形態による分散システムのネットワークノード間で通信されるメッセージの例を描写する図である。
【図１０】本明細書の実装形態による分散システムにおけるネットワークノードの回復処理を行う処理の例を描写する図である。
【図１１】本明細書の実装形態による分散システムにおけるネットワークノードの回復処理を行う処理の例を描写する図である。
【図１２】本明細書の実装形態による分散システムのネットワークノード間で通信されるメッセージの例を描写する図である。
【図１３】本明細書の実装形態によるコンセンサス装置のモジュールを示す図の例を描写する図である。
【図１４】本明細書の実装形態によるコンセンサス装置のモジュールを示す図の例を描写する図である。
【図１５】本明細書の実装形態による１次ノード変更装置のモジュールを示す図の例を描写する図である。
【図１６】本明細書の実装形態による１次ノード変更装置のモジュールを示す図の例を描写する図である。
【図１７】本明細書の実装形態による回復装置のモジュールを示す図の例を描写する図である。
【発明を実施するための形態】
【００３９】
様々な図面における同様の参照符号は、同様の要素を示す。
【００４０】
本明細書の実装形態は、分散システム（例えばブロックチェーンネットワーク）におけるコンセンサス問題に対処するためのコンピュータ実行方法を含む。より具体的には、本明細書の実装形態は、分散システムにおけるネットワークノード間のコンセンサスを実現することを対象とする。
【００４１】
いくつかの実装形態において、アクションは、ブロックチェーンネットワークの１次ノードによって取引要求を受け取ることと、取引要求を使用して１次ノードによってＥＣコードに従っていくつかの消去コード（ＥＣ）ブロックを生成することと、１次ノードによってブロックチェーンネットワークの１つまたは複数のバックアップノードにいくつかの第１のメッセージを送ることであって、いくつかの第１のメッセージのそれぞれが、いくつかのＥＣブロックと関連付けられた合成ハッシュ値を含む、送ることと、バックアップノードのうちの少なくとも１つから１次ノードによって少なくとも１つの第２のメッセージを受け取ることであって、少なくとも１つの第２のメッセージが、いくつかの第１のメッセージのうちの１つ、およびいくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名を含む、受け取ることと、バックアップノードのうちの少なくとも１つからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかを１次ノードによって検証することと、有効な第２のメッセージの数が所定の閾値を超過するかどうかを１次ノードによって判断することと、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて１次ノードによって取引要求を再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、１次ノードによって他のネットワークノードに第３のメッセージを送ることであって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも１つから１次ノードによって少なくとも１つの第３のメッセージを受け取ることと、同一である所定の数の第３のメッセージの受領に応答して、１次ノードによって取引要求を実行することと、を含む。
【００４２】
いくつかの実装形態において、アクションは、１次ノードから第１のメッセージをバックアップノードによって受け取ることであって、第１のメッセージが、複数のＥＣブロックと関連付けられた合成ハッシュ値を含み、複数のＥＣブロックが、取引要求を使用してＥＣコードに従って１次ノードによって生成される、受け取ることと、第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージをバックアップノードによって送ることであって、第２のメッセージが、第１のメッセージおよび第１のメッセージと関連付けられたバックアップノードの署名を含む、送ることと、このバックアップノードによってこのバックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取ることと、少なくとも１つのバックアップノードからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかをバックアップノードによって検証することと、有効な第２のメッセージの数が所定の閾値を超過するかどうかをバックアップノードによって判断することと、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて取引要求をバックアップノードによって再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージをバックアップノードによって送ることであって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージをバックアップノードによって受け取ることと、同一である所定の数の第３のメッセージの受領に応答して、取引要求をバックアップノードによって実行することと、を含む。
【００４３】
本明細書の実装形態に対するさらなる背景を示すために、また上記で紹介されたように、（例えばピアツーピアノードで構成される）コンセンサスネットワークまたはブロックチェーンネットワークと呼ばれることも可能な分散台帳システム（ＤＬＳ）は、参加エンティティが安全かつ不変に取引を行うこと、およびデータを格納することを可能にする。用語ブロックチェーンは、任意の特定のユースケースを参照することなく、全体的にＤＬＳを指すために本明細書で使用される。上記で紹介されたように、ブロックチェーンネットワークは、公開ブロックチェーンネットワーク、プライベートブロックチェーンネットワーク、またはコンソーシアムブロックチェーンネットワークとして提供されることが可能である。
【００４４】
ブロックチェーンは、チェーンに格納された先の全ての取引との一貫性について、将来の取引が検証されるのを可能にする方式で取引を格納するデータ構造である。ブロックチェーンは、１つまたは複数のブロックを含む。チェーン内の各ブロックは、前のブロックの暗号学的ハッシュを含めることによって、チェーン内のブロックの直前の先のブロックにリンクされる。各ブロックは、タイムスタンプ、ブロック自体の暗号学的ハッシュ、および１つまたは複数の取引も含む。ブロックチェーンネットワークのノードによって既に検証された取引は、ハッシュされ、マークル木にエンコードされる。マークル木は、マークル木の葉ノードにあるデータがハッシュされるデータ構造であり、マークル木の各枝における全てのハッシュが、枝のルートにおいて結合される。この処理は、マークル木に沿って、マークル木の中の全てのデータを表すハッシュを格納する木全体のルートまで続く。木に格納された取引のものであるとされるハッシュは、ハッシュが木の構造と一致するものであるかどうかを判断することによって迅速に検証されることが可能である。
【００４５】
ブロックチェーンが取引を格納するためのデータ構造である一方で、ブロックチェーンネットワークは、１つまたは複数のブロックチェーン構造を管理、更新、および維持するコンピューティングノードのネットワークである。上記で紹介されたように、ブロックチェーンネットワークは、公開ブロックチェーンネットワーク、プライベートブロックチェーンネットワーク、またはコンソーシアムブロックチェーンネットワークとして提供されることが可能である。
【００４６】
公開ブロックチェーンネットワークにおいて、コンセンサス処理は、コンセンサスネットワークのノードによって制御される。例えば、何百、何千、何百万ものエンティティでさえ、公開ブロックチェーンネットワークにおいて連携することができ、これらのそれぞれが、公開ブロックチェーンネットワーク内で少なくとも１つのノードを動作させる。したがって、公開ブロックチェーンネットワークは、参加エンティティに対するパブリックネットワークと見なされることが可能である。いくつかの例において、エンティティ（ノード）の大多数は、ブロックが有効になり、ブロックチェーンネットワークのブロックチェーン（分散台帳）に追加されるように、あらゆるブロックに署名しなければならない。公開ブロックチェーンネットワークの例は、ブロックチェーンと呼ばれる分散台帳を活用する特定のピアツーピアの支払ネットワークを含む。上述のように、用語ブロックチェーンは、それでも、いずれの特定のブロックチェーンネットワークに対する特定の参照もなく、分散台帳を一般に指すために使用される。
【００４７】
一般に、公開ブロックチェーンネットワークは、公開取引をサポートする。公開取引は、公開ブロックチェーンネットワーク内のノードの全てによって共有され、グローバルブロックチェーンに格納される。グローバルブロックチェーンは、全てのノードにわたって複製されるブロックチェーンである。すなわち、全てのノードは、グローバルブロックチェーンに対して完璧な状態のコンセンサスになる。コンセンサス（例えばブロックチェーンへのブロックの追加に対する合意）を実現するために、コンセンサスプロトコルが、公開ブロックチェーンネットワーク内で実行される。コンセンサスプロトコルの例は、プルーフオブワーク（ＰＯＷ：  ｐｒｏｏｆ−ｏｆ−ｗｏｒｋ）、プルーフオブステーク（ＰＯＳ：  ｐｒｏｏｆ−ｏｆ−ｓｔａｋｅ）、およびプルーフオブオーソリティ（ＰＯＡ：  ｐｒｏｏｆ−ｏｆ−ａｕｔｈｏｒｉｔｙ）を限定することなく含む。ＰＯＷは、非限定的な例として本明細書でさらに参照される。
【００４８】
一般に、プライベートブロックチェーンネットワークは、読み書き許可を中心に制御する特定のエンティティに提供される。エンティティは、どのノードがブロックチェーンネットワークに参加できるかを制御し、したがって、プライベートブロックチェーンネットワークは、一般に、誰がネットワークに参加することを許されているかに対して、および彼らの参加レベル（例えば一定の取引においてのみ）に対して制約を課す、許可制ネットワーク（ｐｅｒｍｉｓｓｉｏｎｅｄ  ｎｅｔｗｏｒｋ）と呼ばれる。様々なタイプのアクセス制御メカニズムが使用されることが可能である（例えば、既存の参加者が新しいエンティティの追加を採決し、監督機関が入会を制御することができる）。
【００４９】
一般に、コンソーシアムブロックチェーンネットワークは、参加エンティティ間でプライベートなものである。コンソーシアムブロックチェーンネットワークにおいて、コンセンサス処理は、権限付与された一組のノードによって制御され、１つまたは複数のノードは、個々のエンティティ（例えば、金融機関、保険会社）によって運用される。例えば、１０（１０）個のエンティティ（例えば、金融機関、保険会社）のコンソーシアムが、コンソーシアムブロックチェーンネットワークを運用することができ、エンティティのそれぞれは、コンソーシアムブロックチェーンネットワーク内で少なくとも１つのノードを運用する。したがって、コンソーシアムブロックチェーンネットワークは、参加エンティティに対するプライベートネットワークと見なされることが可能である。いくつかの例において、各エンティティ（ノード）は、ブロックが有効になり、ブロックチェーンに追加されるように、あらゆるブロックに署名しなければならない。いくつかの例において、エンティティ（ノード）の少なくともサブセット（例えば少なくとも７つのエンティティ）は、ブロックが有効になり、ブロックチェーンに追加されるように、あらゆるブロックに署名しなければならない。
【００５０】
本明細書の実装形態は、コンソーシアムブロックチェーンネットワークを参照しながら本明細書でさらに詳細に説明される。しかし、本明細書の実装形態は、任意の妥当なタイプのブロックチェーンネットワーク内で実現されることが可能であるということが意図される。
【００５１】
本明細書の実装形態は、上記の背景を考慮して本明細書でさらに詳細に説明される。より具体的には、また上記で紹介されたように、本明細書の実装形態は、分散システムにおけるネットワークノードに対して回復処理を行うことを対象とする。
【００５２】
ブロックチェーンは、公開またはプライベートのピアツーピアネットワークに取引を記録する、改ざん耐性のある共有デジタル台帳である。台帳は、ネットワーク内の全てのメンバノードに配布され、ネットワーク内で発生する資産取引の履歴は、ブロック内に永久に記録される。
【００５３】
コンセンサスメカニズムは、分散ブロックチェーンネットワーク内の全てのネットワークノードが、同じ順序で取引を実行し、その後、同じ台帳に書き込むことを保証する。コンセンサスモデルが対処することを目指す１つの問題は、ビザンチン障害を克服することである。ビザンチン障害において、分散ブロックチェーンネットワークのサーバまたはネットワークノードなどの構成要素は、障害検出システムには故障したようにも、機能しているようにも矛盾して見えることがあり、異なる観察者に異なる症状を示す。他のネットワークノードは、どのネットワークノードが最初に故障したのかについてのコンセンサスに最初に達する必要があるので、構成要素が故障していると宣言して、構成要素をネットワークから切り離すのは他のネットワークノードには困難である。
【００５４】
分散システムの背景において、ビザンチンフォールトトレランス（ＢＦＴ：  Ｂｙｚａｎｔｉｎｅ  ｆａｕｌｔ  ｔｏｌｅｒａｎｃｅ）は、システムの悪意のある構成要素（すなわちブロックチェーンネットワークのネットワークノード）が故障しているか、正しくない情報を他のピアに伝搬させているにもかかわらず、要望通りに機能し、十分なコンセンサスに正しく達するようにする分散コンピュータネットワークの能力である。目的は、ネットワークの正しい機能、およびシステムにおけるまともなノードによって達せられる正しいコンセンサスを、これらの悪意のあるノードが脅かす影響を緩和させることによって壊滅的なシステム障害から守ることである。
【００５５】
しかし、既存のＢＦＴメカニズムは、多くの態様において非効率的であることがわかってきた。例えば、既存のＢＦＴメカニズムは、ビザンチン障害を克服しようとするときの分散ブロックチェーンネットワークに対する実行の複雑性を増加させ、その結果、分散ブロックチェーンネットワークのネットワークノード間の通信に対するレイテンシが増加する。プラクティカルビザンチンフォールトトレランス（ＰＢＦＴ：  Ｐｒａｃｔｉｃａｌ  Ｂｙｚａｎｔｉｎｅ  Ｆａｕｌｔ  Ｔｏｌｅｒａｎｃｅ）は、既存のＢＦＴコンセンサスメカニズムを改良することを目指す最適化のうちの１つである。ＰＢＦＴモデルは、独立ノードの故障、および特定の独立ノードによって伝搬される操作されたメッセージがあるという想定を通じて、ビザンチン障害（悪意のあるノード）に耐性のある実用的なビザンチン状態機械の複製を行うことに焦点を当てる。
【００５６】
ＰＢＦＴモデルにおいて、ノードの全ては順番に並べられ、一方のノードが１次ノード（リーダー）であり、他方がバックアップノードと呼ばれる。システムにおけるノードの全てが互いに通信し、目標は、まともなノードの大多数がシステムの状態の合意に至ることである。ノードは互いに通信して、メッセージが特定のピアノードから来たことを証明しなければならないだけでなく、メッセージが送信中に修正されなかったことを検証する必要もある。
【００５７】
ＰＢＦＴモデルが機能するためには、脆弱性の所与のウィンドウの中で、ネットワーク内の悪意のあるノードの量が、システムにおける全ノードの１／３以上になることができないということが前提となる。システムにおけるノードが多ければ多いほど、全ノードの１／３に近い数が悪意のあるものである可能性が数学的にますます低くなる。アルゴリズムは、多くても（ｎ−１）／３個のノードが同時に悪意のあるものであるか故障している間、生存性（ｌｉｖｅｎｅｓｓ）と安全性の両方を効果的にもたらし、ここで、ｎは、全ノードを表す。
【００５８】
（ビューと呼ばれる）ＰＢＦＴコンセンサスのそれぞれのラウンドは、４つのフェーズを含む。
（１）クライアントは、サービス動作を起動させるためにリーダーノードに要求を送る。
（２）リーダーノードは、バックアップノードに要求をマルチキャストする。
（３）ノードは、要求を実行し、その後、クライアントにリプライを送る。
（４）クライアントは、同じ結果を有する、異なるノードからのｆ＋１個のリプライを待つ（ｆは、故障している可能性のあるノードの最大数を表す）。
最終結果は、全てのまともなノードが、記録の順序について合意に至り、これらのノードが、合意を受け入れるか、拒絶するというものである。リーダーノードは、全てのビューの中で、ラウンドロビン方式で変更され、リーダーノードが要求をマルチキャストすることなく指定の時間が過ぎた場合は、ビュー変更と呼ばれるプロトコルで置き替えられることさえ可能である。まともなノードの大多数は、リーダーが故障しているかどうかを判定し、このリーダーを、代わりとして一列に並んだ次のリーダーを用いて除去することもできる。
【００５９】
しかし、ＰＢＦＴコンセンサスメカニズムにはいくつかの限界がある。例えば、ＰＢＦＴモデルは、ノード間で要求される手に負えない量の通信のため、比較的小さいコンセンサスグループサイズの、このモデルの伝統的な形ではうまく機能することができる。ネットワークノード間で送信される巨大なブロックデータは、ネットワーク負荷問題を引き起こし、ネットワークのボトルネックをもたらす。さらに、ＰＢＦＴモデルにおける認証メッセージのフォーマットとして方法認証コード（ＭＡＣ：  ｍｅｔｈｏｄ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｃｏｄｅ）を使用することは、暗号通貨ネットワークなどの大きいコンセンサスグループにおけるノード間で必要な通信量によって、またＭＡＣによって、非効率になる可能性がある。サードパーティへのメッセージの信憑性を証明することが本来的にできなくなる可能性がある。
【００６０】
さらに、ＰＢＦＴによって使用されるラウンドロビン方法を使用してリーダーノードを変更するときに連続して悪意のあるノードに遭遇することは、まともなリーダーノードを見つける際にレイテンシまたは遅延をもたらすことによってブロックチェーンサービスに影響を及ぼす。例えば、新しいリーダーノードとして第１のネットワークノードを選択するとき、第１のネットワークノードは、悪意のあるノードである可能性があり、したがって新しいリーダーノードとして選択されることは不可能である。ラウンドロビン方法においては、一列に並んだ第２のネットワークノードが、新しいリーダーノードとして選択されることが可能である。しかし、第２のネットワークノードも悪意のあるノードである場合、一列に並んだ別のネットワークノードが、リーダーノードとして適切であるかどうかについて検証されることになる。この処理は、まともな新しいリーダーノードが識別されるまで続く。リーダーノードのこのような頻繁な変更は、ブロックチェーンサービスにおけるかなりのレイテンシをもたらす。
【００６１】
さらに、ブロックチェーンネットワーク内のネットワークノードは、ビザンチン障害またはクラッシュ障害にいつでも遭遇する可能性がある。例えば、ネットワークノードは、悪意のあるサイバー攻撃者によって危険にさらされ、不適当にふるまう可能性がある。危険にさらされるネットワークノードが、即座に回復されない場合、悪意のあるサイバー攻撃者は、検出されることなくネットワークノードの１／３超を壊すことによって、ブロックチェーンネットワークおよびサービスを危険にさらす可能性がある。
【００６２】
既存のＢＦＴコンセンサスメカニズムおよびＰＢＦＴコンセンサスメカニズムと関連付けられた上述の問題および懸念に対処するために、本明細書は、分散システムにおけるネットワークノード間のコンセンサスを実現するため、分散システムにおける１次ノードの変更を行うため、および分散システムにおけるネットワークノードに対する回復処理を行うための技法を含む改良されたコンセンサスメカニズムを開示する。説明されるコンセンサスメカニズムは、様々な用途における様々な長所を実現することができる。
【００６３】
例えば、下記で論じられるようなコンセンサス処理は、ブロックチェーンシステムの動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、説明されるコンセンサス処理は、ＥＣコードに従って取引要求をいくつかの消去コード（ＥＣ）ブロックにコンバートすること、およびネットワークノードのそれぞれにＥＣブロックのうちの１つを送ることを含む。ＥＣブロックは、元の取引要求よりサイズが小さい。したがって、完全な取引要求の代わりにＥＣブロックをネットワークノードに送ることは、ブロックチェーンネットワークのネットワークノード間で送信されるデータブロックのサイズを低減させ、このことにより、ネットワーク帯域幅を節約し、ネットワーク負荷を低減させる。これは、ネットワークノードのメモリ空間との間で読み書きされるデータのサイズをさらに低減させ、このことにより、ネットワークノードのメモリ空間に対する負担を低減させ、全体的なブロックチェーンシステムの効率性を改善する。
【００６４】
さらに、本明細書は、コンセンサス処理の複数のフェーズに個々の重みを割り当てること、複数のフェーズの個々の重みに基づいて加重和を判断すること、および加重和に基づいて新しい１次ノードを判断することを含むエポック変更処理を説明する。ラウンドロビン方法の代わりの加重和に基づくエポック変更処理は、故障していない新しい１次ノードをタイムリに選ぶことを容易にすることができる。１次ノードは、１次ノードを含むいくつかのネットワークノード間のコンセンサス処理のラウンドを始める権限を有するリーダーノードであることが可能である。ブロックチェーンネットワークの他のネットワークノードは、バックアップノードと呼ばれることが可能である。エポック変更処理は、新しい１次ノードに対して一列に並んだ複数のネットワークノードが故障しているときに、１次ノードの頻繁な変更を引き起こすラウンドロビン方法の問題に対処するのに役立つ可能性がある。ラウンドロビン方式とは異なり、本明細書におけるエポック変更処理は、加重和に応じて新しい１次ノードを選択し、これは、故障していない新しい１次ノードを見つける際のレイテンシまたは遅延を低減させることができる。これは、ブロックチェーンサービスを提供する際の全体的なブロックチェーンシステムの効率性をさらに改善することができる。
【００６５】
さらに、本明細書は、新しい１次ノードとして使用されるネットワークノードによって状態要求メッセージを送ること、および他のネットワークノードから状態リプライメッセージを受け取ることなどの動作を含む回復処理を論じる。これらの動作は、故障しているネットワークノードの回復処理が、他の故障していないネットワークノード間のコンセンサス処理の正常動作に支障を来さないように行われる。これは、回復処理の複雑性を低減させることによって故障しているネットワークノードを回復させるためのコンピューティングリソースおよびネットワークリソースを節約することを容易にする。
【００６６】
図１は、本明細書の実装形態を実行するために使用されることが可能な環境１００の例を描写する。いくつかの例において、環境１００は、コンソーシアムブロックチェーンネットワーク１０２にエンティティが参加することを可能にする。環境１００は、コンピューティングデバイスまたはシステム１０６、１０８、およびネットワーク１１０を含む。いくつかの例において、ネットワーク１１０は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット、またはこれらの組合せを含み、ウェブサイト、ユーザデバイス（例えばコンピューティングデバイス）、およびバックエンドシステムを接続する。いくつかの例において、ネットワーク１１０は、有線および／またはワイヤレス通信リンクでアクセスされることが可能である。いくつかの例において、ネットワーク１１０は、コンソーシアムブロックチェーンネットワーク１０２との通信、およびコンソーシアムブロックチェーンネットワーク１０２内での通信を可能にする。全体的に、ネットワーク１１０は、１つまたは複数の通信ネットワークを表す。いくつかのケースにおいて、コンピューティングデバイス１０６、１０８は、クラウドコンピューティングシステム（図示せず）のノードであることが可能であり、また各コンピューティングデバイス１０６、１０８は、ネットワークによって相互接続され、分散処理システムとして機能する複数のコンピュータを含む別々のクラウドコンピューティングシステムであることが可能である。
【００６７】
描写された例において、コンピューティングシステム１０６、１０８は、それぞれ、コンソーシアムブロックチェーンネットワーク１０２にノードとして参加することを可能にする任意の妥当なコンピューティングシステムを含むことができる。コンピューティングデバイスの例は、サーバ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピューティングデバイス、およびスマートフォンを限定することなく含む。いくつかの例において、コンピューティングシステム１０６、１０８は、コンソーシアムブロックチェーンネットワーク１０２と対話するために１つまたは複数のコンピュータ実行サービスをホストする。例えば、コンピューティングシステム１０６は、１つまたは複数の他のエンティティ（例えば他のユーザ）との第１のエンティティの取引を管理するために第１のエンティティが使用する取引管理システムなどの、第１のエンティティ（例えばユーザＡ）のコンピュータ実行サービスをホストすることができる。コンピューティングシステム１０８は、１つまたは複数の他のエンティティ（例えば他のユーザ）との第２のエンティティの取引を管理するために第２のエンティティが使用する取引管理システムなどの、第２のエンティティ（例えばユーザＢ）のコンピュータ実行サービスをホストすることができる。図１の例において、コンソーシアムブロックチェーンネットワーク１０２は、ノードのピアツーピアネットワークとして表され、コンピューティングシステム１０６、１０８は、コンソーシアムブロックチェーンネットワーク１０２に参加する第１のエンティティおよび第２のエンティティのそれぞれのノードを提供する。
【００６８】
図２は、本明細書の実装形態による概念アーキテクチャ２００の例を描写する。概念アーキテクチャ２００の例は、参加者Ａ、参加者Ｂ、および参加者Ｃにそれぞれ対応する参加者システム２０２、２０４、２０６を含む。各参加者（例えば、ユーザ、企業）は、複数のノード２１４を含むピアツーピアネットワークとして提供されるブロックチェーンネットワーク２１２に参加し、複数のノード２１４のうちの少なくともいくつかは、ブロックチェーン２１６に情報を不変に記録する。単一のブロックチェーン２１６が、ブロックチェーンネットワーク２１２内に概略的に描写されているが、本明細書でさらに詳細に説明されるように、ブロックチェーンネットワーク２１２の全体にわたってブロックチェーン２１６の複数のコピーがあり、維持される。
【００６９】
描写された例において、各参加者システム２０２、２０４、２０６は、参加者Ａ、参加者Ｂ、および参加者Ｃのそれぞれによって、またはこれらの代わりに提供され、ブロックチェーンネットワーク内の個々のノード２１４として機能する。本明細書で使用されるように、ノードは、一般に、ブロックチェーンネットワーク２１２に接続され、個々の参加者がブロックチェーンネットワークに参加することを可能にする、個々のシステム（例えば、コンピュータ、サーバ）を指す。図２の例において、参加者は、各ノード２１４に対応する。しかし参加者は、ブロックチェーンネットワーク２１２内で複数のノード２１４を動作させることができ、および／または複数の参加者は、ノード２１４を共有することができるということが意図される。いくつかの例において、参加者システム２０２、２０４、２０６は、プロトコル（例えばハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ））を使用して、および／またはリモートプロシージャコール（ＲＰＣ）を使用して、ブロックチェーンネットワーク２１２と通信するか、ブロックチェーンネットワーク２１２を介して通信する。
【００７０】
ノード２１４は、ブロックチェーンネットワーク２１２内で様々な度合いの参加を行うことができる。例えば、ノード２１４の中には、（例えばブロックチェーン２１６にブロックを追加する監視ノード（ｍｉｎｄｅｒ  ｎｏｄｅ）として）コンセンサス処理に参加できるものもある一方で、他のノード２１４は、コンセンサス処理には参加しない。別の例として、ノード２１４の中には、ブロックチェーン２１６の完全コピーを格納するものもある一方で、他のノード２１４は、ブロックチェーン２１６の一部のコピーしか格納しない。例えば、データアクセス権は、個々の参加者の個々のシステムに個々の参加者が格納するブロックチェーンデータを制限することができる。図２の例において、参加者システム２０２、２０４、２０６は、ブロックチェーン２１６の個々の完全コピー２１６’、２１６’’、２１６’’’を格納する。
【００７１】
ブロックチェーン（例えば図２のブロックチェーン２１６）はブロックのチェーンで構成され、各ブロックがデータを格納する。データの例は、２つ以上の参加者の間の取引を表す取引データを含む。非限定的な例として取引が本明細書で使用されるが、任意の妥当なデータ（例えば、文書、画像、ビデオ、オーディオ）がブロックチェーンに格納されることが可能であるということが意図される。取引の例は、何らかの価値（例えば、資産、製品、サービス、および通貨）の交換を限定することなく含むことができる。取引データは、ブロックチェーン内に不変に格納される。すなわち、取引データが変更されることは不可能である。
【００７２】
ブロックに格納する前に、取引データはハッシュされる。ハッシングは、（文字列データとして提供される）取引データを（同様に文字列データとして提供される）固定長ハッシュ値に変換する処理である。ハッシュ値をアンハッシュして取引データを入手することは不可能である。ハッシングは、取引データのわずかな変更でさえ、完全に異なるハッシュ値を生じることを保証する。さらに、また上述のように、ハッシュ値は固定長のものである。すなわち、取引データのサイズに関係なく、ハッシュ値の長さは固定される。ハッシングは、ハッシュ関数によって取引データを処理し、ハッシュ値を生成することを含む。ハッシュ関数の例は、２５６ビットハッシュ値を出力するセキュアハッシュアルゴリズム（ＳＨＡ）−２５６を限定することなく含む。
【００７３】
複数の取引の取引データはハッシュされ、ブロックに格納される。例えば、２つの取引のハッシュ値が提供され、このハッシュ値自体がハッシュされて別のハッシュをもたらす。この処理は、全ての取引がブロックに格納されるために、単一のハッシュ値が提供されるまで繰り返される。このハッシュ値は、マークルルートハッシュと呼ばれ、ブロックのヘッダに格納される。取引のいずれかの変更は、取引のハッシュ値の変更、および最終的にマークルルートハッシュの変更を生じることになる。
【００７４】
ブロックは、コンセンサスプロトコルを通じてブロックチェーンに追加される。ブロックチェーンネットワーク内の複数のノードは、コンセンサスプロトコルに参加し、ブロックをブロックチェーンに追加することを競う。このようなノードは、マイナー（ｍｉｎｅｒ）（または監視ノード）と呼ばれる。上記で紹介されたＰＯＷは、非限定的な例として使用される。
【００７５】
マイナーノードは、コンセンサス処理を実行して、ブロックチェーンに取引を追加する。複数のマイナーノードがコンセンサス処理に参加するが、ただ１つのマイナーノードしか、ブロックチェーンにブロックを書き込むことができない。すなわち、マイナーノードは、コンセンサス処理において、自分のブロックをブロックチェーンに追加することを競う。さらに詳細には、マイナーノードは、（例えば、もしあれば、ブロックに含まれることが可能な取引数に対する所定の限界まで）取引プールから未決の取引を定期的に収集する。取引プールは、ブロックチェーンネットワークの参加者からの取引メッセージを含む。マイナーノードはブロックを構築し、ブロックに取引を追加する。ブロックに取引を追加する前に、マイナーノードは、取引のいずれかがブロックチェーンのブロックに既に含まれているかどうかをチェックする。取引が別のブロックに既に含まれている場合、取引は廃棄される。
【００７６】
マイナーノードはブロックヘッダを生成し、ブロック内の取引の全てをハッシュし、単一のハッシュ値がブロック内の全ての取引に提供されるまでハッシュ値をさらに生成するために２つ１組でハッシュ値を組み合わせる（マークルルートハッシュ）。このハッシュはブロックヘッダに追加される。マイナーは、ブロックチェーン内の最も新しいブロックのハッシュ値（すなわちブロックチェーンに追加される最後のブロック）も判断する。マイナーノードは、ノンス値およびタイムスタンプもブロックヘッダに追加する。マイニング処理において、マイナーノードは、必要なパラメータを満たすハッシュ値を見つけようと試みる。マイナーノードは、必要なパラメータを満たすハッシュ値を見つけるまでノンス値を変更し続ける。
【００７７】
ブロックチェーンネットワーク内の全てのマイナーは、必要なパラメータを満たすハッシュ値を見つけようと試み、このようにして、互いに競う。最終的に、マイナーノードのうちの１つが、必要なパラメータを満たすハッシュ値を見つけ、このことを、ブロックチェーンネットワーク内の他の全てのマイナーノードに知らせる。他のマイナーノードはハッシュ値を検証し、正しいと判断されると、ブロック内の各取引を検証し、ブロックを受け入れ、ブロックチェーンのこれらのコピーにブロックを付加する。このように、ブロックチェーンのグローバル状態は、ブロックチェーンネットワーク内の全てのマイナーノードの全体にわたって一致している。上述の処理は、ＰＯＷコンセンサスプロトコルである。
【００７８】
図２を参照しながら非限定的な例が提供される。この例において、参加者Ａは、ある程度の資金を参加者Ｂに送ることを望む。参加者Ａは、（例えば、Ｆｒｏｍフィールド、Ｔｏフィールド、および値フィールドを含む）取引メッセージを生成し、ブロックチェーンネットワークに取引メッセージを送り、ブロックチェーンネットワークは、取引メッセージを取引プールに追加する。ブロックチェーンネットワーク内の各マイナーノードはブロックを作り出し、（例えば、もしあれば、ブロックに追加されることが可能な取引数に対する所定の限度まで）取引プールから全ての取引を入手し、ブロックに取引を追加する。このように、参加者Ａによって公表された取引は、マイナーノードのブロックに追加される。
【００７９】
いくつかのブロックチェーンネットワークにおいて、取引のプライバシーを維持するために暗号法が実行される。例えば、ブロックチェーンネットワーク内の他のノードが取引の詳細を見分けられないように２つのノードが取引をプライベートに保つことを望む場合、ノードは、取引データを暗号化することができる。暗号化方法の例は、対称暗号化および非対称暗号化を限定することなく含む。対称暗号化は、暗号化（平文から暗号文を生成すること）、および複合（暗号文から平文を生成すること）の両方のために単一キーを使用する暗号化処理を指す。対称暗号化において、複数のノードに対して同じキーが利用できるので、各ノードは、取引データを暗号化すること／復号することができる。
【００８０】
非対称暗号化は、それぞれが秘密鍵および公開鍵を含むキーのペアを使用し、秘密鍵は個々のノードにだけ知られており、公開鍵は、ブロックチェーンネットワーク内のいずれかまたは他の全てのノードに知られている。ノードは、別のノードの公開鍵を使用してデータを暗号化することができ、暗号化されたデータは、他のノードの秘密鍵を使用して復号されることが可能である。例えば、また図２を再度参照すると、参加者Ａは、参加者Ｂの公開鍵を使用してデータを暗号化し、暗号化されたデータを参加者Ｂに送ることができる。参加者Ｂは、参加者Ｂの秘密鍵を使用して暗号化されたデータ（暗号文）を復号し、元のデータ（平文）を抽出することができる。ノードの公開鍵で暗号化されたメッセージは、このノードの秘密鍵を使用して復号されること以外は不可能である。
【００８１】
非対称暗号化は、取引の参加者が、取引の他の参加者ならびに取引の有効性を確認することを可能にするデジタル署名を行うために使用される。例えば、ノードはメッセージにデジタル的に署名することができ、別のノードは、参加者Ａのデジタル署名に基づいてノードによってメッセージが送られたことを確認することができる。デジタル署名は、移送中にメッセージが改ざんされていないことを保証するために使用されることも可能である。例えば、また図２を再度参照すると、参加者Ａは、メッセージを参加者Ｂに送ることになる。参加者Ａはメッセージのハッシュを生成し、次に、参加者Ａの秘密鍵を使用してハッシュを暗号化し、暗号化されたハッシュとしてデジタル署名を行う。参加者Ａはデジタル署名をメッセージに付加し、デジタル署名付きのメッセージを参加者Ｂに送る。参加者Ｂは、参加者Ａの公開鍵を使用してデジタル署名を復号し、ハッシュを抽出する。参加者Ｂはメッセージをハッシュし、ハッシュを比較する。ハッシュが同じ場合、参加者Ｂは、メッセージが実際に参加者Ａからのものであったこと、および改ざんされていなかったことを確認することができる。
【００８２】
図３は、本明細書の実装形態に従って実行されることが可能な分散システム（例えばブロックチェーンネットワーク１０２および２１２）のネットワークノード（例えばノード２１４）間のコンセンサスを実現するための処理３００の例を描写する。具体的には、図３は、本明細書による通常のケースにおけるコンセンサスを実現する方法３００の例示的実施形態を提示する図を示す。図３において示されるように、コンセンサス処理３００は、下記で論じられるような３つのフェーズ、すなわちステージ３１０、３２０、および３３０を含む。
【００８３】
コンセンサス処理３００の第１のフェーズ３１０において、ブロックチェーンネットワークの１次ノード（またはリーダーノード）は、他のネットワークノード（すなわちバックアップノード）に第１のメッセージを送る。第１のメッセージは、１次ノードがコンセンサス処理を始めていることを示す。例えば、図３において示されるように、１次ノードＲ０は、ブロックチェーンネットワーク内の他のネットワークノードＲ１、Ｒ２、およびＲ３にＩＮＩＴＩＡＬメッセージを送る。処理３００は、例証のためだけに４つのネットワークノードＲ０、Ｒ１、Ｒ２、およびＲ３を含むものとして示されるが、処理３００は、任意の適切な数のネットワークノードを含むことができるということに留意されたい。第１のフェーズ、およびＩＮＩＴＩＡＬメッセージのフォーマットは、図４〜図６を参照しながら、より詳細に下記で論じられることになる。
【００８４】
コンセンサス処理３００の第２のフェーズ３２０において、バックアップノードのそれぞれは、１次ノードによって送られる第１のメッセージを受け取り、第１のメッセージに応答して第２のメッセージを用意し、他のネットワークノードに第２のメッセージをマルチキャストする。第２のメッセージは、バックアップノードが１次ノードから第１のメッセージを受け取ったこと、および第１のメッセージに応答してリプライを送っていることを示す。例えば、図３において示されるように、バックアップノードＲ１は、１次ノードＲ０によって送られているＩＮＩＴＩＡＬメッセージを受け取り、第２のメッセージの例としてＥＣＨＯメッセージで１次ノードＲ０にリプライする。一方で、バックアップノードＲ１は、バックアップノードＲ２およびＲ３などの他のバックアップノードにもＥＣＨＯメッセージをマルチキャストする。同様に、バックアップノードＲ２およびＲ３は、それそれ、１次ノードＲ０を含む他のネットワークノードにＥＣＨＯメッセージをマルチキャストする。
【００８５】
例えば１次ノードまたはバックアップノードなどのネットワークノードが、他のネットワークノードからＥＣＨＯメッセージを受け取るとき、ネットワークノードは、ＥＣＨＯメッセージ内の情報を検証することができる。第２のフェーズおよびＥＣＨＯメッセージのフォーマットは、図４〜図６を参照しながら、より詳細に下記で論じられることになる。
【００８６】
コンセンサス処理３００の第３のフェーズ３３０において、ネットワークノードのそれぞれは、他のネットワークノードに第３のメッセージをマルチキャストする。第３のメッセージは、ネットワークノードが所定の数の第２のメッセージを受け入れたことを示す。いくつかの実装形態において、第３のメッセージは、ネットワークノードが、取引を実行する用意ができたということを示すことができる。いくつかの実装形態において、第３のメッセージは、ネットワークノードにおいて取引が成功裏に再構築されたことを示すことができる。例えば、図３において示されるように、１次ノードＲ０は、バックアップノードＲ１、Ｒ２、およびＲ３にＡＣＣＥＰＴメッセージをマルチキャストする。同様に、バックアップノードＲ１、Ｒ２、およびＲ３は、それぞれ、他のネットワークノードにＡＣＣＥＰＴメッセージをマルチキャストする。本明細書のいくつかの実装形態において、ＡＣＣＥＰＴメッセージをマルチキャストする前に、ネットワークノードは、消去コード（ＥＣ）に従ってＡＣＣＥＰＴが送られるかどうか、およびＥＣＨＯメッセージ内の情報が、第２のフェーズにおいて受け取られたものであるかどうかを判断する。第３のフェーズ、ＥＣコード、およびＡＣＣＥＰＴメッセージのフォーマットは、図４〜図６を参照しながら、より詳細に下記で論じられることになる。
【００８７】
ネットワークノードが他のネットワークノードから十分なＡＣＣＥＰＴメッセージを受け取ると、ネットワークノードは、コンセンサスが実現されたと判断する。例えば、１次ノードＲ０またはバックアップノードＲ１、Ｒ２、またはＲ３が、定足数（例えば２ｆ＋１、ここでｆは、故障しているネットワークノードの数を表す）のＡＣＣＥＰＴメッセージを受け取ると、ネットワークノード間でコンセンサスが自動的に実現される。
【００８８】
図４は、本明細書の実装形態に従って実行されることが可能な分散システム（例えばブロックチェーンネットワーク１０２または２１２）のネットワークノード（例えばノード２１４またはノードＲ０、Ｒ１、Ｒ２、およびＲ３）間でコンセンサスを実現するための処理４００の例を描写する。いくつかの実装形態において、処理４００は、１つまたは複数のコンピューティングデバイスを使用して実行される１つまたは複数のコンピュータ実行可能プログラムを使用して行われることが可能である。表現の明瞭さのために、続く説明は、全体的に、本説明における他の図の背景において方法４００を説明する。方法４００は、例えば、任意の適切なシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって必要に応じて行われることが可能であるということが理解されよう。いくつかの実装形態において、方法４００の様々なステップは、並行に、組み合わせて、ループさせて、または任意の順序で実行されることが可能である。
【００８９】
初めに、処理４００は、図１〜図３において示されたようなシステム１００〜システム３００と共に実行されることが可能である。本明細書のいくつかの実装形態において、ブロックチェーンネットワーク１０２および／または２１２は、１次ノード４０４および１つまたは複数のバックアップノード４０６を含む。ブロックチェーンネットワーク１０２および／または２１２は、ブロックチェーンサービスを提供するためにネットワーク１１０を介してクライアントノード４０２などの、コンピューティングシステム１０６および／または１０８と通信する。クライアントノード４０２、１次ノード４０４、およびバックアップノード４０６のそれぞれは、本明細書で論じられる処理を行うように構成された専用コンピュータまたは他のデータ処理装置であることが可能である。例えば、クライアントノード４０２は、ブロックチェーンネットワークと相互作用するクライアント端末またはクライアントデバイスと呼ばれることも可能である。クライアントノード４０２は、ブロックチェーンネットワークにアクセスするため、およびブロックチェーンネットワークと通信するためにブロックチェーンネットワークと接続状態にある、例えばクライアントアプリケーションまたはクライアントソフトウェア開発キット（ＳＤＫ）をインストールすることができる。１次ノード４０４および１つまたは複数のバックアップノード４０６は、コンセンサスを実現し、ブロックチェーンネットワークに情報を不変に記録するコンセンサスノードまたはネットワークノードと呼ばれることも可能である。
【００９０】
処理４００は、４０８において始まり、ここで、クライアントノード４０２は、取引要求を生成する。本明細書のいくつかの実装形態において、取引要求は、ブロックチェーンネットワーク１０２および／または２１２からのブロックチェーンサービスを要求する要求を含むことができる。
【００９１】
４１０において、クライアントノード４０２は、ブロックチェーンネットワーク１０２および／または２１２の１次ノード４０４に取引要求をマルチキャストする。本明細書のいくつかの実装形態において、１次ノード４０４は、クライアントノード４０２から取引要求を受け取った後に取引要求を追跡するために、取引要求にシーケンス番号を割り当てる。
【００９２】
４１２において、１次ノード４０２は、クライアントノード４０２から取引要求を受け取った後に、いくつかのＥＣブロックを生成する。本明細書のいくつかの実装形態において、１次ノード４０４は、取引要求を使用してＥＣコードに従っていくつかのＥＣブロックを生成する。例えば、図５を参照すると、１次ノード４０４は、取引要求５０２に対してＥＣコード５０４を適用し、ＥＣコード５０４を使用して取引要求５０２をＥＣメッセージ５０６に変換する。ＥＣコード５０４は、ビット消去の前提に基づく前方誤り訂正（ＦＥＣ）コードである。ＥＣコード５０４は、元の取引要求５０２がＥＣメッセージ５０６の一部または断片から回復されることが可能になるように、元の取引要求５０２をより長いＥＣメッセージ５０６に変換する。
【００９３】
本明細書のいくつかの実装形態において、ＥＣコード５０４は、Ｔｏｒｎａｄｏコードまたは低密度パリティ検査符号などの、ほぼ最適な消去コードである。本明細書の代替実装形態において、ＥＣコード５０４は、ファウンテンコード、オンラインコード、Ｌｕｂｙ変換（ＬＴ）コード、またはラプターコードなどの、ほぼ最適なファウンテンコードである。本明細書の代替実装形態において、ＥＣコード５０４は、パリティコード、Ｐａｒｃｈｉｖｅコード、リードソロモンコード、または再生成コードなどの、最適な消去コードである。本明細書のいくつかの実装形態において、ＥＣコード５０４は、任意の適切なタイプの消去コードであることが可能である。
【００９４】
取引要求５０２をＥＣメッセージ５０６に変換した後、１次ノード４０４は、ＥＣメッセージ５０６を使用して、いくつかのＥＣブロック５０８を生成する。例えば、図５において示されるように、１次ノード４０４は、ＥＣメッセージ５０６を分割することによって、ＥＣブロックＡ、ＥＣブロックＢ、ＥＣブロックＣ、およびＥＣブロックＤという４つのＥＣブロック５０８を生成する。ＥＣブロック５０８は、例証のために４つのブロックを含むものとして図５において示されているが、ＥＣブロック５０８は、任意の適切な数のＥＣブロック５０８を含むものとして生成されることが可能であるということに留意されたい。ＥＣブロック５０８は、ＩＮＩＴＩＡＬメッセージの中で個々のバックアップノード４０６に送られることになる。
【００９５】
本明細書のいくつかの実装形態において、ＥＣブロック５０８は同じサイズを有する。しかし、代替実装形態において、ＥＣブロック５０８は、互いに異なるサイズを有することができる。
【００９６】
本明細書のいくつかの実装形態において、１次ノード４０４は、ＥＣブロック５０８を使用してハッシュ木５００（例えばマークル木）を生成する。ハッシュ木５００は、データブロックのハッシュでラベル付けされたいくつかの葉ノード、および非葉ノードの子ノードのラベルの暗号学的ハッシュでラベル付けされたいくつかの非葉ノードを含む。例えば、図５に示されたように、ハッシュ木５００は、４つの葉ノード５１０の個々のＥＣブロック５０８の暗号学的ハッシュとして生成されたハッシュＡ、ハッシュＢ、ハッシュＣ、およびハッシュＤという４つの葉ノード５１０、４つの非葉ノード５１２の個々の子ノード５１０の連鎖のハッシュとして生成された４つの非葉ノード５１２、および非葉ノード５１４の子ノード５１２のハッシュとして生成され、ハッシュ木５００のルートハッシュである非葉ノード５１４を含むものとして構成される。
【００９７】
ハッシュ木５００は、大きいデータ構造の内容の効率的かつ安全な検証を可能にする。ハッシュ木５００は、コンピュータ内で、またコンピュータ間で格納され、取り扱われ、移送される任意の種類のデータを検証するために使用されることが可能である。ハッシュ木５００は、Ｐ２Ｐネットワーク内の他のピアから受け取られたデータブロックが無傷であり変更されずに受け取られることを保証すること、および他のピアが偽造ブロックを送っていないことをチェックすることにさえ役立つ可能性がある。ハッシュ木５００を使用するデータブロックの検証が、コンセンサス処理４００の以下のステップを参照しながら、より詳細に下記で論じられることになる。
【００９８】
図４を再度参照すると、１次ノード４０４は、ＥＣブロック５０８およびハッシュ木５００を生成した後、第１のメッセージ（例えばＩＮＩＴＩＡＬメッセージ）を生成する。第１のメッセージは、１次ノードがコンセンサス処理を始めていることを示す。いくつかの実装形態において、第１のメッセージの例としてのＩＮＩＴＩＡＬメッセージは、ＥＣブロック５０８およびハッシュ木５００内の情報を使用して生成される。本明細書のいくつかの実装形態において、図６を参照すると、ＩＮＩＴＩＡＬメッセージは、＜ｅｐｏｃｈ，  ｔｘ＿ｒｏｏｔ＿ｈａｓｈ，  ｅｃ＿ｂｌｏｃｋ＿ｈａｓｈ，  ｅｃ＿ｂｌｏｃｋ，  ｓｅｑ，  ｊ＞というフォーマットを有し、ここで、「ｅｐｏｃｈ」は、メッセージが送られているコンセンサスのラウンドを表し、「ｔｘ＿ｒｏｏｔ＿ｈａｓｈ」は、ハッシュ木５００内のルートハッシュ５１４を表し、「ｅｃ＿ｂｌｏｃｋ＿ｈａｓｈ」は、ハッシュ木５００内のハッシュ５１０および／または５１２を表し、「ｅｃ＿ｂｌｏｃｋ」は、ハッシュ木５００内のＥＣブロック５０８を表し、「ｓｅｑ」は、取引要求５０２と関連付けられたシーケンス番号を表し、「ｊ」は、ＩＮＩＴＩＡＬメッセージを生成して送るネットワークノードを表す。いくつかの実装形態において、ＩＮＩＴＩＡＬメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【００９９】
図４を再度参照すると、４１６において、コンセンサス処理の第１のフェーズにおいて、１次ノード４０４は、他のネットワークノード（例えばバックアップノード４０６）にＩＮＩＴＩＡＬメッセージをマルチキャストする。いくつかの実装形態において、バックアップノード４０６に送られるＩＮＩＴＩＡＬメッセージは、＜ｅｐｏｃｈ，  ｔｘ＿ｒｏｏｔ＿ｈａｓｈ，  ｅｃ＿ｂｌｏｃｋ＿ｈａｓｈ，  ｅｃ＿ｂｌｏｃｋ，  ｓｅｑ，  ｊ＞というフォーマットを有する。例えば、１次ノード４０４は、第１のＩＮＩＴＩＡＬメッセージ＜ｅｐｏｃｈ  １，  Ｈａｓｈ  ＡＢＣＤ，  ｛Ｈａｓｈ  Ｂ，  Ｈａｓｈ  Ｃ，  Ｈａｓｈ  Ｄ｝，  ＥＣ  ｂｌｏｃｋ  Ａ，  １，  ０＞を第１のバックアップノード４０６に送ること、および第２のＩＮＩＴＩＡＬメッセージ＜ｅｐｏｃｈ  １，  Ｈａｓｈ  ＡＢＣＤ，  ｛Ｈａｓｈ  Ａ，  Ｈａｓｈ  Ｃ，  Ｈａｓｈ  Ｄ｝，  ＥＣ  ｂｌｏｃｋ  Ｂ，  １，  ０＞を第２のバックアップノード４０６に送ること、などを行うことができる。「ｅｃ＿ｂｌｏｃｋ」などのＩＮＩＴＩＡＬメッセージ内の情報は、ハッシュ木５００を再構築するために「ｅｃ＿ｂｌｏｃｋ＿ｈａｓｈ」と共に使用されることが可能であるということに留意されたい。例えば、第１のＩＮＩＴＩＡＬメッセージ＜ｅｐｏｃｈ  １，  Ｈａｓｈ  ＡＢＣＤ，  ｛Ｈａｓｈ  Ｂ，  Ｈａｓｈ  Ｃ，  Ｈａｓｈ  Ｄ｝，  ＥＣ  ｂｌｏｃｋ  Ａ，  １，  ０＞において、「ＥＣブロックＡ」というＥＣブロック５０８は、「Ｈａｓｈ  Ａ」という暗号学的ハッシュ５１０を生成するためにハッシュされることが可能であり、「Ｈａｓｈ  Ａ」は、ハッシュ木５００を再構築するために「｛Ｈａｓｈ  Ｂ，  Ｈａｓｈ  Ｃ，  Ｈａｓｈ  Ｄ｝」という他のハッシュ５１０と共にさらに使用される。再構築されたハッシュ木５００は、コンセンサス処理の以下のステップを参照しながら、より詳細に下記で論じられるような、ＥＣＨＯメッセージを検証するために使用されることになる。
【０１００】
４１８において、バックアップノード４０６のそれぞれは、１次ノード４０４からＩＮＩＴＩＡＬメッセージを受け取った後、コンセンサス処理の第２のフェーズにおいて第２のメッセージ（例えばＥＣＨＯメッセージ）を生成する。第２のメッセージは、バックアップノードが１次ノードから第１のメッセージを受け取ったということを示す。第２のメッセージは、第１のメッセージに応答してリプライとして送られる。本明細書のいくつかの実装形態において、ＥＣＨＯメッセージは、ＩＮＩＴＩＡＬメッセージまたはＩＮＩＴＩＡＬメッセージの一部、およびＩＮＩＴＩＡＬメッセージと関連付けられたバックアップノード４０６の署名を含むものとしてバックアップノード４０６によって生成される。例えば、バックアップノード４０６は、秘密鍵を使用して、ＩＮＩＴＩＡＬメッセージまたはＩＮＩＴＩＡＬメッセージのダイジェストに署名することによって署名を生成することができる。秘密鍵署名は、秘密鍵署名を含むＥＣＨＯメッセージを認証するために、秘密鍵とペアになる公開鍵を使用して、他のネットワークノードによって使用されることが可能である。
【０１０１】
本明細書のいくつかの実装形態において、図６を参照すると、ＥＣＨＯメッセージは、＜ｅｐｏｃｈ，  ｔｘ＿ｒｏｏｔ＿ｈａｓｈ，  ｅｃ＿ｂｌｏｃｋ＿ｈａｓｈ，  ｅｃ＿ｂｌｏｃｋ，  ｓｅｑ，  ｓｉｇｎ＿ｐｒｏｏｆ，  ｊ＞というフォーマットを有し、ここで、「ｅｐｏｃｈ」は、メッセージが送られているコンセンサスのラウンドを表し、「ｔｘ＿ｒｏｏｔ＿ｈａｓｈ」は、ハッシュ木５００内のルートハッシュ５１４を表し、「ｅｃ＿ｂｌｏｃｋ＿ｈａｓｈ」は、ハッシュ木５００内のハッシュ５１０および／または５１２を表し、「ｅｃ＿ｂｌｏｃｋ」は、個々のバックアップノード４０６によって受け取られるハッシュ木５００内のＥＣブロック５０８を表し、「ｓｅｑ」は、取引要求５０２と関連付けられたシーケンス番号を表し、「ｓｉｇｎ＿ｐｒｏｏｆ」は、ＩＮＩＴＩＡＬメッセージと関連付けられたバックアップノード４０６の署名を表し、「ｊ」は、ＥＣＨＯメッセージを生成して送るネットワークノードを表す。いくつかの実装形態において、ＥＣＨＯメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【０１０２】
図４を再度参照すると、４２０において、バックアップノード４０６は、１次ノード４０４にＥＣＨＯメッセージを送る。４２１において、バックアップノード４０６のそれぞれは、他のバックアップノード４０６にＥＣＨＯメッセージを送る。４２３において、バックアップノード４０６のそれぞれは、他のバックアップノード４０６からＥＣＨＯメッセージを受け取ることができる。
【０１０３】
４２２において、１次ノード４０４は、バックアップノード４０６によって送られたＥＣＨＯメッセージを検証する。本明細書のいくつかの実装形態において、１次ノード４０４は、ハッシュ木５００に従ってＥＣＨＯメッセージが有効であるかどうかを検証する。例えば、１次ノード４０４は、第１のＥＣＨＯメッセージ＜ｅｐｏｃｈ  １，  Ｈａｓｈ  ＡＢＣＤ，  ｛Ｈａｓｈ  Ｂ，  Ｈａｓｈ  Ｃ，  Ｈａｓｈ  Ｄ｝，  ＥＣ  ｂｌｏｃｋ  Ａ，  １，  １＞を第１のバックアップノード４０６から受け取ることができる。１次ノード４０４は、「ＥＣブロックＡ」というＥＣブロック５０８をメッセージから取得し、「ＥＣブロックＡ」をハッシュして、「ハッシュＡ」という暗号学的ハッシュ５１０を生成する。１次ノード４０４は、メッセージ内の「｛Ｈａｓｈ  Ｂ，  Ｈａｓｈ  Ｃ，  Ｈａｓｈ  Ｄ｝」という他のハッシュ５１０と共に、「ハッシュＡ」という生成されたハッシュ５１０をさらに使用して、ハッシュ木５００を再構築する。次に、１次ノード４０４は、再構築されたハッシュ木５００のルートハッシュ５１４を判断し、このルートハッシュ５１４を、「Ｈａｓｈ  ＡＢＣＤ」などのＥＣＨＯメッセージ内のルートハッシュ５１４と比較する。２つのルートハッシュ５１４がマッチする場合、１次ノード４０４は、ＥＣＨＯメッセージが有効であると判断する。１次ノード４０４は、有効なＥＣＨＯメッセージを格納すること、および無効であると判断されたＥＣＨＯメッセージを廃棄することができる。
【０１０４】
４２４において、１次ノード４０４は、有効なＥＣＨＯメッセージの数が所定の閾値を超過するかどうかを判断する。本明細書のいくつかの実装形態において、１次ノード４０４は、有効なＥＣＨＯメッセージの数が、定足数ｎ−ｆまたは２ｆ＋１に達しているかどうかを判断し、ここで、ｎは、ネットワークノードの総数であり、ｆは、ネットワークが許容できる故障ノードの最大数である。
【０１０５】
４２６において、１次ノード４０４は、有効なＥＣＨＯメッセージの数が定足数に達したとの判断に応答して取引要求５０２を再構築する。本明細書のいくつかの実装形態において、１次ノード４０４は、ＥＣコードに従って有効なＥＣＨＯメッセージの少なくともサブセットに基づいて取引要求５０２を再構築する。例えば、１次ノード４０４は、有効なＥＣＨＯメッセージの定足数（例えばｎ−ｆまたは２ｆ＋１）の範囲内のｎ−２ｆ個またはｆ＋１個のＥＣブロック５０８を取得し、取得したＥＣブロック５０８を使用してＥＣコード５０４に従って取引要求５０２を再構築することができる。
【０１０６】
４２８において、コンセンサス処理の第３のフェーズにおいて、１次ノード４０４は、取引要求５０２が成功裏に再構築されたとの判断に応答して、第３のメッセージ（例えばＡＣＣＰＥＴメッセージ）を生成する。第３のメッセージは、ネットワークノードが所定の数の第２のメッセージを受け入れたことを示す。いくつかの実装形態において、第３のメッセージは、ネットワークノードが取引を実行する用意ができたということを示すことができる。いくつかの実装形態において、第３のメッセージは、ネットワークノードにおいて取引が成功裏に再構築されたことを示すことができる。例えば、ＡＣＣＰＥＴメッセージは、取引要求５０２が成功裏に再構築されたことを他のネットワークノードに示すために使用されることが可能である。１次ノード４０４が、取引要求５０２を再構築するのに失敗した場合、１次ノード４０４は、ＡＣＣＥＰＴメッセージを生成することができない。
【０１０７】
本明細書のいくつかの実装形態において、図６を参照すると、ＡＣＣＥＰＴメッセージは、＜ｅｐｏｃｈ，  ｔｘ＿ｒｏｏｔ＿ｈａｓｈ，  ｓｅｑ，  ｓｉｇｎ＿ｐｒｏｏｆｓ，  ｊ＞というフォーマットを有し、ここで、「ｅｐｏｃｈ」は、メッセージが送られているコンセンサスのラウンドを表し、「ｔｘ＿ｒｏｏｔ＿ｈａｓｈ」は、ハッシュ木５００内のルートハッシュ５１４を表し、「ｓｅｑ」は、取引要求５０２と関連付けられたシーケンス番号を表し、「ｓｉｇｎ＿ｐｒｏｏｆｓ」は、有効なＥＣＨＯメッセージ内の署名のセットを表し、「ｊ」は、ＡＣＣＥＰＴメッセージを生成して送るネットワークノードを表す。いくつかの実装形態において、ＡＣＣＥＰＴメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することが可能である。
【０１０８】
図４を再度参照すると、４３０において、１次ノード４０４は、バックアップノード４０６にＡＣＣＰＥＴメッセージを送る。
【０１０９】
１次ノード４０４と同様に、バックアップノード４０６のそれぞれは、例えば１次ノード４０４としてステップ４２２〜ステップ４２８と同様のステップを行うことによって、取引要求を再構築することができる。４３２において、バックアップノード４０６のそれぞれは、バックアップノード４０６によって取引要求５０２が成功裏に再構築したとの判断に応答して、ＡＣＣＥＰＴメッセージを生成する。いくつかの実装形態において、１次ノード４０４およびバックアップノード４０６は、例えば図３において示されるように、ステップ４２２〜ステップ４２８を並列に行うことができる。
【０１１０】
４３４において、バックアップノード４０６は、１次ノード４０４にＡＣＣＥＰＴメッセージを送る。一方で、バックアップノード４０６のそれぞれは、他のバックアップノード４０６にＡＣＣＥＰＴメッセージを送ることができる。
【０１１１】
４３６において、１次ノード４０４は、ＡＣＣＥＰＴメッセージの数が所定の閾値を超過しているとの判断に応答して、取引要求５０２を実行する。本明細書のいくつかの実装形態において、１次ノード４０４は、受け取ったＡＣＣＥＰＴメッセージが同一であるかどうか、および同一であるＡＣＣＥＰＴメッセージの数が定足数（例えば２ｆ＋１）に達しているかどうかを判断する。同一のＡＣＣＥＰＴメッセージの数が定足数に達していると、１次ノード４０４は、ネットワークノード全体の間でコンセンサスが実現されたと判断し、次に、取引要求５０２をローカルに実行する。本明細書のいくつかの実装形態において、同一であるＡＣＣＥＰＴメッセージの数が定足数に達していないと１次ノード４０４が判断すると、１次ノード４０４は、ネットワークノード全体の間でコンセンサスが実現されなかったと判断し、その後、取引要求５０２を実行するのを控える。
【０１１２】
本明細書のいくつかの実装形態において、バックアップノード４０６のそれぞれは、取引要求５０２を実行する前に、４３６において上述のような、１次ノード４０４によって行われる同じ動作を行うことができる。バックアップノード４０６が受け取るＡＣＣＥＰＴメッセージが所定の閾値を超過しているとバックアップノード４０６が判断すると、バックアップノード４０６は、ネットワークノード間でコンセンサスが実現されたと判断し、取引要求５０２をローカルに実行する。本明細書のいくつかの実装形態において、同一であるＡＣＣＥＰＴメッセージの数が定足数に達していないとバックアップノード４０６が判断すると、バックアップノード４０６は、ネットワークノード全体の間でコンセンサスが実現されなかったと判断し、その後、取引要求５０２を実行するのを控える。
【０１１３】
４３８において、１次ノード４０４は、取引要求５０２を実行した後、クライアントノード４０２に取引結果を送る。取引要求５０２をローカルに成功裏に実行したバックアップノード４０６は、取引要求５０２の個々の取引結果をクライアントノード４０２に送ることもできる。
【０１１４】
上述のようなコンセンサス処理は、ブロックチェーンシステム全体の動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、本明細書におけるコンセンサス処理は、取引要求を使用してＥＣコードに従っていくつかのＥＣブロックを生成し、ネットワークノードのそれぞれにＥＣブロックのうちの１つを送ることを含む。ＥＣブロックは、元の取引要求よりサイズが小さい。したがって、取引要求の代わりにＥＣブロックをネットワークノードに送ることは、ブロックチェーンネットワークのネットワークノード間で送信されるデータブロックのサイズを低減させ、このことにより、ネットワーク帯域幅を節約し、ネットワーク負荷を低減させる。これは、ネットワークノードのメモリ空間との間で読み書きされるデータのサイズをさらに低減させ、このことにより、ネットワークノードのメモリ空間に対する負担を低減させ、全体的なブロックチェーンシステムの効率性を改善する。
【０１１５】
コンセンサス処理の間、バックアップノードは、１次ノードからの要求を待っている。しかし、１次ノードは、ビザンチン障害またはクラッシュ障害に遭遇する可能性があり、その結果、１次ノードは、所定の時間ウィンドウの中で要求をブロードキャストすることができない。１次ノードが要求をマルチキャストすることなく指定の時間が過ぎると、実行すべき要求をバックアップノードが無期限に待つのを防ぐために新しい１次ノードが選ばれる必要がある可能性がある。
【０１１６】
図７は、本明細書の実装形態に従って実行されることが可能な分散システム（例えばブロックチェーンネットワーク１０２および２１２）の１次ノードの変更（例えばノード２１４または４０４）を行うための処理７００の例を描写する。具体的には、図７は、本明細書による、１次ノードの変更を行う方法７００の例示的実施形態を提示する図を示す。いくつかの実装形態において、１次ノードは、１次ノードがリーダーであるコンセンサス処理を含むエポックと関連付けられる。１次ノードの変更は、エポックの変更をもたらすことが可能である。
【０１１７】
いくつかの実装形態において、現在のエポックの１次ノードが変更される必要があるとの判断に応答して、ブロックチェーンネットワークのバックアップノードは、他のネットワークノードに第１のメッセージを送る。第１のメッセージは、新しいエポックにおける新しい１次ノードであることをバックアップノードが望んでいることを示す。例えば、図７において示されたように、バックアップノードＲ０は、現在の１次ノードが故障しており、エポック変更が行われる必要があるとのバックアップノードＲ０の判断に応答して、ブロックチェーンネットワーク内の他のネットワークノードＲ１、Ｒ２、およびＲ３にＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを送る。ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、バックアップノードＲ０が新しい１次ノードとして使用されることを示す第１のメッセージの１つの例である。エポック変更は、現在の１次ノードによる現在のエポックから、新しい１次ノードによる新しいエポックへの変更を引き起こすことができる。処理７００は、例証のためだけに４つのネットワークノードによって実行されるものとして示されているということに留意されたい。処理７００は、任意の適切な数のネットワークノードによって実行されることが可能である。
【０１１８】
次に、ネットワークノードのそれぞれは、バックアップノードによって送られた第１のメッセージを受け取り、第１のメッセージに応答して第２のメッセージを用意し、他のネットワークノードに第２のメッセージをマルチキャストする。例えば、図７において示されたように、ネットワークノードＲ１は、バックアップノードＲ０によって送られたＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを受け取り、バックアップノードＲ０が新しい１次ノードになることができるという承認を示すＮＥＷ＿ＥＰＯＣＨメッセージと共にバックアップノードＲ０にリプライする。一方で、ネットワークノードＲ１は、ネットワークノードＲ２およびＲ３などの他のネットワークノードにもＮＥＷ＿ＥＰＯＣＨメッセージをマルチキャストする。同様に、ネットワークノードＲ２およびＲ３はそれぞれ、他のネットワークノードにＮＥＷ＿ＥＰＯＣＨメッセージをマルチキャストする。
【０１１９】
上述のようなエポック変更処理、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのフォーマット、およびＮＥＷ＿ＥＰＯＣＨメッセージのフォーマットは、図８〜図９を参照しながら、より詳細に下記で論じられることになる。
【０１２０】
図８は、本明細書の実装形態に従って実行されることが可能な分散システム（例えばブロックチェーンネットワーク１０２または２１２）における１次ノードの変更を行うための処理８００の例を描写する。いくつかの実装形態において、処理８００の例は、１つまたは複数のコンピューティングデバイスを使用して実行される１つまたは複数のコンピュータ実行可能プログラムを使用して行われることが可能である。表現の明瞭さのために、続く説明は、全体的に、本説明における他の図の背景において方法８００を説明する。方法８００は、例えば、任意の適切なシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって必要に応じて行われることが可能であるということが理解されよう。いくつかの実装形態において、方法８００の様々なステップは、並行に、組み合わせて、ループさせて、または任意の順序で実行されることが可能である。
【０１２１】
処理８００は、８０６において始まり、ここで、バックアップノード８０２は、エポック変更が行われる必要があると判断する。本明細書で論じられるエポック変更は、現在の１次ノードによる現在のエポックから、新しい１次ノードによる新しいエポックへの変更を引き起こす。エポックの例は、図３〜図６を参照しながら上述されたように、１次ノードを使用して、いくつかのネットワークノード間のコンセンサスを実現するためのコンセンサス処理（例えばコンセンサス処理３００または４００）を含むことができる。
【０１２２】
本明細書のいくつかの実装形態において、バックアップノード８０２は、現在の１次ノードからの要求を受け取ることなく指定の時間が過ぎた後、現在の１次ノードからの要求をバックアップノード８０２がまだ待っているとの判断に応答して、エポック変更が行われる必要があると判断する。例えば、現在の１次ノードは、ビザンチン障害またはクラッシュ障害に遭遇する可能性があり、その結果、現在の１次ノードは、所定の時間ウィンドウの中で要求をマルチキャストすることができない。したがって、実行すべき要求をバックアップノードが無期限に待つのを防ぐタイムアウトによってエポック変更が誘発される。本明細書で論じられるエポック変更処理は、生存性をもたらし、１次ノードが故障したときにシステムが進行するのを可能にすることによって、ネットワークレイテンシを低減させる。
【０１２３】
８０８において、バックアップノード８０２は、現在のエポックにおけるコンセンサス処理のフェーズのそれぞれと関連付けられたバックアップノード８０２の個々の重みを判断する。いくつかの実装形態において、コンセンサス処理は、図３〜図６を参照しながら上述されたような３つのフェーズを含む。重みは、新しいエポックにおいて新しい１次ノードになるためのバックアップノード８０２の資格の測定基準である。
【０１２４】
本明細書のいくつかの実装形態において、バックアップノード８０２は、現在のエポックにおけるコンセンサス処理の第１のフェーズに対するバックアップノード８０２の重みが第１の値であると判断する。例えば、バックアップノード８０２は、コンセンサス処理の第１のフェーズ（例えばコンセンサス処理３００の第１のフェーズ３１０）にバックアップノード８０２が入った場合、初期の重み１０％を割り当てられることが可能である。本明細書の代替実装形態において、バックアップノード８０２は、現在のコンセンサス処理の第１のフェーズに対するバックアップノード８０２に任意の適切な重み値を割り当てることができる。
【０１２５】
本明細書のいくつかの実装形態において、バックアップノード８０２は、定足数検証処理に基づいて、現在のエポックにおけるコンセンサス処理の第２のフェーズ（例えばコンセンサス処理３００の第２のフェーズ３２０）に対するバックアップノード８０２の重みを判断する。定足数検証処理は、コンセンサス処理の第２のフェーズにおいて所定の数（例えば２ｆ＋１）のＥＣＨＯメッセージをバックアップノード８０２が他のネットワークノードから受け取ったかどうかを判断することによって行われる。
【０１２６】
本明細書のいくつかの実装形態において、バックアップノード８０２が定足数検証に失敗すると（例えば、所定の閾値より少ないいくつかのＥＣＨＯメッセージをバックアップノード８０２が受け取る）、バックアップノード８０２は、コンセンサス処理の第２のフェーズに対するバックアップノード８０２の重みが第１の値であると判断することができる。バックアップノード８０２が定足数検証にパスすると（例えば、所定の閾値以上のいくつかのＥＣＨＯメッセージをバックアップノード８０２が受け取る）、バックアップノード８０２は、コンセンサス処理の第２のフェーズに対するバックアップノード８０２の重みが第２の値であると判断することができる。本明細書のいくつかの実装形態において、第２の値は、第１の値より大きいものと判断される。例えば、バックアップノード８０２が定足数検証に失敗すると、バックアップノード８０２は、コンセンサス処理の第２のフェーズに対して、重み値ゼロを割り当てられることが可能である。バックアップノード８０２が定足数検証にパスすると、バックアップノード８０２は、コンセンサス処理の第２のフェーズに対するバックアップノード８０２に対して重み値４５％を割り当てられることが可能である。しかし、本明細書の代替実装形態において、バックアップノード８０２は、現在のエポックにおけるコンセンサス処理の第２のフェーズに対するバックアップノード８０２に任意の適切な値を割り当てることができる。
【０１２７】
本明細書のいくつかの実装形態において、定足数検証は、コンセンサス処理の第２のフェーズ中にバックアップノード８０２が他のネットワークノードから受け取ったＥＣＨＯメッセージが有効であるかどうかを検証することをさらに含む。例えば、バックアップノード８０２は、ＥＣＨＯメッセージが有効であるかどうかを判断するための公開鍵を使用して、ＥＣＨＯメッセージ内の秘密鍵署名を認証することができる。
【０１２８】
第２のフェーズに対して重みを判断することと同様に、いくつかの実装形態において、バックアップノード８０２は、定足数検証処理に基づいて、現在のエポックにおけるコンセンサス処理の第３のフェーズ（例えばコンセンサス処理３００の第３のフェーズ３３０）に対するバックアップノード８０２の重みを判断する。定足数検証処理は、現在のエポックにおけるコンセンサス処理の第３のフェーズにおいて、所定の数（例えば２ｆ＋１）の受け入れメッセージをバックアップノード８０２が他のネットワークノードから受け取ったかどうかを判断することによって行われる。他のネットワークノードからの受け入れメッセージのそれぞれは、他のネットワークノードのそれぞれが所定の数のＥＣＨＯメッセージを受け入れたということを示す。受け入れメッセージは、例えば、コンセンサス処理３００の第３のフェーズ３３０を参照しながら上述されたＡＣＣＥＰＴメッセージであることが可能である。
【０１２９】
本明細書のいくつかの実装形態において、バックアップノード８０２が定足数検証に失敗すると（例えば、所定の閾値より少ないいくつかのＡＣＣＥＰＴメッセージをバックアップノード８０２が受け取る）、バックアップノード８０２は、コンセンサス処理の第３のフェーズに対するバックアップノード８０２の重みが第１の値であると判断することができる。バックアップノード８０２が定足数検証にパスすると（例えば、所定の閾値以上のいくつかのＡＣＣＥＰＴメッセージをバックアップノード８０２が受け取る）、バックアップノード８０２は、コンセンサス処理の第３のフェーズに対するバックアップノード８０２の重みが第２の値であると判断することができる。いくつかの実装形態において、第２の値は、第１の値より大きいものと判断される。例えば、バックアップノード８０２が定足数検証に失敗すると、バックアップノード８０２は、コンセンサス処理の第２のフェーズに対するバックアップノード８０２に対して重み値ゼロを割り当てられることが可能である。バックアップノード８０２が定足数検証にパスすると、バックアップノード８０２は、コンセンサス処理の第２のフェーズに対するバックアップノード８０２に対する重み値４５％を割り当てられることが可能である。しかし、本明細書の代替実装形態において、バックアップノード８０２は、現在のエポックにおけるコンセンサス処理の第３のフェーズに対するバックアップノード８０２に任意の適切な値を割り当てることができる。
【０１３０】
８１０において、現在のエポックにおけるコンセンサス処理のフェーズに対してバックアップノード８０２の個々の重みを判断した後、バックアップノード８０２は、個々の重みに基づいてコンセンサス処理に対するバックアップノード８０２の加重和を判断する。本明細書のいくつかの実装形態において、加重和は、現在のエポックにおけるコンセンサス処理のフェーズのそれぞれと関連付けられたバックアップノードの個々の合計の合計である。例えば、第１のフェーズに対するバックアップノード８０２の第１の重み値が１０％であり、第２のフェーズに対するバックアップノード８０２の第２の重み値が４５％であり、第３のフェーズに対するバックアップノード８０２の第３の重み値が４５％であるとバックアップノード８０２が判断した場合、バックアップノード８０２は加重和を１００％であると判断する。別の例として、第１のフェーズに対するバックアップノード８０２の第１の重み値が１０％であり、第２のフェーズに対するバックアップノード８０２の第２の重み値が４５％であり、第３のフェーズに対するバックアップノード８０２の第３の重み値が０であるとバックアップノード８０２が判断すると、バックアップノード８０２は加重和が５５％であると判断する。
【０１３１】
８１２において、バックアップノード８０２は、８１０において判断された加重和が所定の閾値に達しているか超過しているとバックアップノード８０２が判断すると、他のネットワークノード８０４にＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを送る。例えば、バックアップノード８０２は、８１０において判断されたような加重和が１００％に達すると、他のネットワークノード８０４にＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを送ることができる。ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、現在の１次ノードによる現在のエポックから、バックアップノードが新しい１次ノードになる新しいエポックへの変更のための要求を示す。
【０１３２】
本明細書のいくつかの実装形態において、図９を参照すると、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、＜ｗｅｉｇｈｔ，  ｅｐｏｃｈ＋１，  ＥＣＨＯ｛｝，  ＡＣＣＥＰＴ｛｝，  ｊ＞というフォーマットを有し、ここで、「ｗｅｉｇｈｔ」は、コンセンサス処理に対する、８１０において以前に判断されたような、バックアップノード８０２の加重和を表し、「ｅｐｏｃｈ＋１」は、新しい１次ノードと関連付けられた新しいコンセンサスのラウンド（すなわち新しいエポック）を表し、「ＥＣＨＯ｛｝」は、コンセンサス処理の第２のフェーズ中にバックアップノード８０２が受け取ったＥＣＨＯメッセージのセットを表し、「ＡＣＣＥＰＴ｛｝」は、コンセンサス処理の第３のフェーズ中にバックアップノード８０２が受け取ったＡＣＣＥＰＴメッセージのセットを表し、「ｊ」は、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを生成して送るネットワークノード（例えばバックアップノード８０２）を表す。いくつかの実装形態において、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、例えば、追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【０１３３】
図８を再度参照すると、８１４において、バックアップノード８０２以外のネットワークノード８０４は、バックアップノード８０２によって送られたＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを検証する。いくつかの実装形態において、ネットワークノード８０４のそれぞれは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の加重和が有効であるかどうかを検証することによって、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であるかどうかを検証する。いくつかの実装形態において、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の加重和が有効であるかどうかを検証することは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージに含まれるＥＣＨＯメッセージ内の署名のセットが有効であるかどうかを検証することを含む。例えば、ネットワークノード８０４のそれぞれは、公開鍵を使用してＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを含んだＥＣＨＯメッセージ内の秘密鍵署名のセットを認証することができる。
【０１３４】
８１６において、ネットワークノード８０４のそれぞれは、バックアップノード８０２によって送られたＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であることの検証に応答して、バックアップノード８０２にＮＥＷ＿ＥＰＯＣＨメッセージを送る。ＮＥＷ＿ＥＰＯＣＨメッセージは、新しい１次ノードにバックアップノードがなることについての承認を示す。例えば、ネットワークノード８０４によって送られたＮＥＷ＿ＥＰＯＣＨメッセージは、バックアップノード８０２が新しいエポックにおける新しい１次ノードになることをネットワークノード８０４が承認するという指示を含む。一方で、ネットワークノード８０４のそれぞれは、他のネットワークノード８０４にもＮＥＷ＿ＥＰＯＣＨメッセージを送る。
【０１３５】
図９を参照すると、ＮＥＷ＿ＥＰＯＣＨメッセージは、＜ｅｐｏｃｈ＋１，  ｉ，  ｊ，  ｓｅｑ，  ｅｃ＿ｄｉｇｅｓｔ＞というフォーマットを有するものとして生成しており、ここで、「ｅｐｏｃｈ＋１」は、新しい１次ノードと関連付けられた新しいコンセンサスのラウンド（すなわち新しいエポック）を表し、「ｉ」は、新しいエポックにおける新しい１次ノードを表し、「ｊ」は、ＮＥＷ＿ＥＰＯＣＨメッセージを送るネットワークノード８０４を表し、「ｅｃ＿ｄｉｇｅｓｔ」は、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストを表す。いくつかの実装形態において、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのハッシュ値を含む。いくつかの実装形態において、ＮＥＷ＿ＥＰＯＣＨメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【０１３６】
図８を再度参照すると、８１８において、バックアップノード８０２は、ネットワークノード８０４によって送られたＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証する。いくつかの実装形態において、バックアップノード８０２は、ＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することによってＮＥＷ＿ＥＰＯＣＨメッセージを検証する。ダイジェストはＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージの情報を含むので、ダイジェストは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の署名も含む。バックアップノード８０２は、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の署名のセットが有効であるかどうかを検証することによってＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストを検証することができる。
【０１３７】
８２０において、バックアップノード８０２は、８１８において判断されるような有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過するかどうかを判断する。いくつかの実装形態において、所定の閾値は定足数（例えば２ｆ＋１）である。
【０１３８】
８２２において、バックアップノード８０２は、判断されたような有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過したとの判断に応答して、バックアップノード８０２が新しいエポックにおける新しい１次ノードであると判断する。ネットワークノード８０４のそれぞれは、バックアップノード８０２が行うのと同じステップ８１８〜ステップ８２２を行い、ネットワークノード８０４およびバックアップノード８０２は、ステップ８１８〜ステップ８２２を並列に行うことができるということに留意されたい。例えば、ネットワークノード８０４のそれぞれは、他のネットワークノード８０４から送られたＮＥＷ＿ＥＰＯＣＨメッセージのセットを検証し、有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過しているかどうかを判断し、新しい１次ノードを判断することができる。
【０１３９】
上述のようなエポック変更処理（例えば処理７００または８００）は、ブロックチェーンシステム全体の動作を改善し、ネットワークのボトルネックを緩和させるのに役立つ多くの特徴を含む。例えば、本明細書におけるエポック変更処理は、コンセンサス処理の３つのフェーズに個々の重みを割り当てること、３つのフェーズの個々の重みに基づいて加重和を判断すること、および加重和に基づいて新しい１次ノードを判断することを含む。ラウンドロビン方法の代わりの加重和に基づくエポック変更処理は、故障していない新しい１次ノードをタイムリに選ぶことを容易にすることができる。ラウンドロビン方法は、新しい１次ノードに対して一列に並んだ複数のネットワークノードが故障しているときに、１次ノードの頻繁な変更を引き起こす可能性がある。これは、故障していない１次ノードを見つける際にレイテンシまたは遅延をもたらすことによってブロックチェーンサービスに著しく影響を及ぼす。ラウンドロビン方法とは異なり、本明細書におけるエポック変更処理は、加重和に応じて新しい１次ノードを選択し、これは、故障していない新しい１次ノードを見つける際の時間を低減させることができる。これは、ブロックチェーンサービスを提供する際の全体的なブロックチェーンシステムの効率性をさらに改善することができる。
【０１４０】
ブロックチェーンネットワークの動作中、いくつかのネットワークノードの実行速度は、ネットワークジタリング（ｎｅｔｗｏｒｋ  ｊｉｔｔｅｒｉｎｇ）、突然の電源障害、ディスク障害、および同様のもののために、ほとんどのネットワークノードの実行速度より遅れることがある。このシナリオにおいて、システムにおけるネットワークノードの１／３超が、故障する可能性がある。ＢＦＴは、ネットワークノードの１／３未満がシステムの存続時間中に故障する場合の安全性および生存性をもたらす。しかし、これらの保証は、上述のようなシナリオにおいて上限を超過する可能性があるので、長寿命のシステムには不十分である。したがって、ネットワークノードの存続期間にわたってｆ個超の障害をシステムが許容できるように、故障しているネットワークノードを再度正しく動作させ、その後のコンセンサス処理に参加し続けるという回復処理が望ましい。さらに、説明される回復処理は、コンセンサス処理（例えばコンセンサス処理３００または４００）をまだ行っている１つまたは複数のネットワークノードを回復させることができ、ネットワークノード全体の間でコンセンサスが達せられるまで待つ必要はない。したがって、説明される回復処理は、システムのレイテンシをさらに低減させ、ブロックチェーンネットワークの効率性を改善することができる。
【０１４１】
図１０は、本明細書の実装形態に従って実行されることが可能な分散システム（例えばブロックチェーンネットワーク１０２および２１２）のネットワークノード（例えばノード２１４または４０４）の回復処理を行うための処理１０００の例を描写する。具体的には、図１０は、本明細書によるネットワークノードの回復処理を行う方法１０００の例示的実施形態を提示する図を示す。図１０において示されたように、処理１０００は、いくつかのフェーズおよびステージを含む。
【０１４２】
第１のフェーズ１０１０において、対象シーケンス番号Ｒ０の対象取引を回復させることを望むネットワークノード（例えばネットワークノードＲ０）は、ネットワークノードが回復されることになることを示す状態要求メッセージ（例えばＱＵＥＲＹ＿ＳＴＡＴＥメッセージ）を他のネットワークノードにマルチキャストする。状態要求メッセージは、ネットワークノードＲ０が回復させることを望む対象シーケンス番号を含むことができる。第２のフェーズ１０２０において、他のネットワークノードは、状態要求メッセージを受け取り、状態リプライメッセージ（例えばＲＥＰＬＹ＿ＳＴＡＴＥメッセージ）をネットワークノードＲ０に送る。第３のフェーズ１０３０において、ネットワークノードＲ０は、他のネットワークノードのそれぞれからのＥＣＨＯメッセージを要求する要求メッセージ（例えばＦＥＴＣＨ＿ＥＣＨＯメッセージ）を他のネットワークノードに送る。ＥＣＨＯメッセージは、図３〜図６を参照しながら上記で論じられたような、コンセンサス処理３００の第２のフェーズ３２０において個々の他のネットワークノードによって送られた同じＥＣＨＯメッセージであることが可能である。第４のフェーズ１０４０において、他のネットワークノードのそれぞれは、ＦＥＴＣＨ＿ＥＣＨＯメッセージに応答して、ネットワークノードＲ０にＥＣＨＯメッセージを送る。第５のフェーズ１０５０において、ネットワークノードＲ０はＥＣＨＯメッセージを検証し、例えば図４を参照しながら上述されたような再構築技法の例に従って、ＥＣコードに従って対象取引を回復させる。第６のフェーズ１０６０において、ネットワークノードＲ０は、ネットワークノードが回復されたことを示すＡＣＣＥＰＴメッセージを他のネットワークノードに送る。
【０１４３】
処理１０００は、例証のためだけに４つのネットワークノードと共に実行されものとして示されているということに留意されたい。処理１０００は、任意の適切な数のネットワークノードと共に実行されることが可能である。処理１０００、ＱＵＥＲＹ＿ＳＴＡＴＥメッセージのフォーマット、およびＲＥＰＬＹ＿ＳＴＡＴＥメッセージのフォーマットは、図１１〜図１２を参照しながら、より詳細に下記で論じられることになる。
【０１４４】
図１１は、本明細書の実装形態に従って実行されることが可能な分散システム（例えばブロックチェーンネットワーク１０２または２１２）におけるネットワークノードの回復処理を行うための処理１１００の例を描写する。いくつかの実装形態において、処理１１００は、１つまたは複数のコンピューティングデバイスを使用して実行される１つまたは複数のコンピュータ実行可能プログラムを使用して行われることが可能である。表現の明瞭さのために、続く説明は、全体的に、本説明における他の図の背景において方法１１００を説明する。方法１１００は、例えば任意の適切なシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって、必要に応じて行われることが可能であるということが理解されよう。いくつかの実装形態において、方法１１００の様々なステップは、並行に、組み合わせて、ループさせて、または任意の順序で実行されることが可能である。
【０１４５】
処理１１００は、１１０６において始まり、ここで、ネットワークノード１１０２は、他のネットワークノード１１０４に状態要求メッセージをマルチキャストする。状態要求メッセージは、対象シーケンス番号の対象取引をネットワークノード１１０２が回復させることになるという指示を含む。ネットワークノード１１０２は、１次ノードまたはバックアップノードであることが可能である。
【０１４６】
本明細書のいくつかの実装形態において、図１２を参照すると、ＱＵＥＲＹ＿ＳＴＡＴＥメッセージは、状態要求メッセージの例として、＜ｊ，  ｓｅｑ＞というフォーマットを有し、ここで、「ｊ」は、ＱＵＥＲＹ＿ＳＴＡＴＥメッセージを送るネットワークノード１１０２を表し、「ｓｅｑ」は、現在のコンセンサス処理におけるネットワークノード１１０２に対する最大のシーケンス番号または最も新しいシーケンス番号を表す。いくつかの実装形態において、ＱＵＥＲＹ＿ＳＴＡＴＥメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【０１４７】
他のネットワークノード１１０４にＱＵＥＲＹ＿ＳＴＡＴＥメッセージをブロードキャストすることによって、ネットワークノード１１０２は、他のネットワークノードの最も新しいシーケンス番号をネットワークノード１１０２に送ることを、他のネットワークノード１１０４に要求しており、このことにより、ブロックチェーンシステムの最新のブロック情報を入手する。また、ブロックチェーンシステム全体の最新のブロック情報を入手することによって、ネットワークノード１１０２は、システム全体の最新のステータスに同期できる可能性があり、このことにより、ネットワークノード１１０２自体を回復させ、コンセンサス処理に参加し続ける。
【０１４８】
図１１を再度参照すると、１１０８において、他のネットワークノード１１０４のそれぞれは、状態要求メッセージの受領に応答して、状態リプライメッセージ（例えばＲＥＰＬＹ＿ＳＴＡＴＥメッセージ）をネットワークノード１１０２に送る。いくつかの実装形態において、状態リプライメッセージは、ネットワークノード１１０４と関連付けられた以前のシーケンス番号を含む。
【０１４９】
いくつかの実装形態において、図１２を参照すると、ＲＥＰＬＹ＿ＳＴＡＴＥメッセージは、状態リプライメッセージの例として、＜ｊ，  ｌａｓｔ＿ｓｅｑ＞というフォーマットを有し、ここで、「ｊ」は、ＲＥＰＬＹ＿ＳＴＡＴＥメッセージを送るネットワークノード１１０４を表し、「ｌａｓｔ＿ｓｅｑ」は、現在のコンセンサス処理におけるネットワークノード１１０４に対する以前のシーケンス番号を表す。いくつかの実装形態において、ＲＥＰＬＹ＿ＳＴＡＴＥメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【０１５０】
図１１を再度参照すると、１１１０において、ネットワークノード１１０２は、受け取られた状態リプライメッセージの数が所定の閾値を超過するかどうかを判断する。例えば、ネットワークノード１１０２は、受け取られたＲＥＰＬＹ＿ＳＴＡＴＥメッセージの数が定足数（例えば２ｆ＋１またはｎ−ｆ）を超過するかどうかを判断することができる。いくつかの実装形態において、ネットワークノード１１０２は、受け取られたＲＥＰＬＹ＿ＳＴＡＴＥメッセージの定足数が同一のシーケンス番号を含むかどうかをさらに判断する。受け取られたＲＥＰＬＹ＿ＳＴＡＴＥメッセージの定足数は、ネットワークノード１１０４の大多数がシステム全体の共通の状態に合意することを意味する同一のシーケンス番号を含む。
【０１５１】
１１１２において、ネットワークノード１１０２は、ネットワークノード１１０４から受け取られた同一のシーケンス番号を含む状態リプライメッセージの数が所定の閾値を超過するとネットワークノード１１０２が判断すると、同一のシーケンス番号に基づいて対象シーケンス番号を判断する。例えば、ネットワークノード１１０２は、対象シーケンス番号が同一のシーケンス番号（例えば「ｌａｓｔ＿ｓｅｑ」）の増分（例えば「ｌａｓｔ＿ｓｅｑ＋１」）であると判断することができる。
【０１５２】
１１１４において、ネットワークノード１１０２は、要求メッセージ（例えばＦＥＴＣＨ＿ＥＣＨＯメッセージ）を他のネットワークノード１１０４に送る。ＦＥＴＣＨ＿ＥＣＨＯメッセージは、他のネットワークノード１１０４のそれぞれからＥＣＨＯメッセージを要求するために、ネットワークノード１１０２によって送られる。図３〜図６を参照しながら上記で論じられたように、ＥＣＨＯメッセージは、対象取引に対するネットワークノード１１０４間のコンセンサスを実現するためにネットワークノード１１０４によって送信されたメッセージである。ＥＣＨＯメッセージは、対象取引の一部（例えばＥＣブロック）、およびＥＣＨＯメッセージを送るネットワークノード１１０４の署名を含む。
【０１５３】
いくつかの実装形態において、図１２を参照すると、ＦＥＴＣＨ＿ＥＣＨＯメッセージは、要求メッセージの例として、＜ｊ，  ｌａｓｔ＿ｓｅｑ＋１＞というフォーマットを有し、ここで、「ｊ」は、ＦＥＴＣＨ＿ＥＣＨＯメッセージを送るネットワークノード１１０２を表し、「ｌａｓｔ＿ｓｅｑ＋１」は、ネットワークノード１１０２が要求している他のネットワークノード１１０４からのＥＣＨＯメッセージと関連付けられた対象シーケンス番号を表す。いくつかの実装形態において、ＦＥＴＣＨ＿ＥＣＨＯメッセージは、例えば追加のフィールドまたは異なるフィールドを含めることによって、異なるフォーマットを有することができる。
【０１５４】
本明細書で論じられるようなＦＥＴＣＨ＿ＥＣＨＯメッセージは、他のネットワークノード１１０４からの最も新しいシーケンス番号または最大のシーケンス番号を含むＥＣＨＯメッセージを要求するために、ネットワークノード１１０２によって送られる。他のネットワークノード１１０４からの最も新しいシーケンス番号または最大のシーケンス番号を含むＥＣＨＯメッセージを収集することによって、ネットワークノード１１０２は、最も新しいシーケンス番号と関連付けられた最も新しい状態に回復させることができる可能性がある。
【０１５５】
図１１を再度参照すると、１１１６において、ネットワークノード１１０４のそれぞれは、ＦＥＴＣＨ＿ＥＣＨＯメッセージの受領に応答して、ネットワークノード１１０２にＥＣＨＯメッセージを送る。いくつかの実装形態において、ネットワークノード１１０４のそれぞれは、ネットワークノード１１０２にＥＣＨＯメッセージを送る前にＦＥＴＣＨ＿ＥＣＨＯメッセージを検証する。いくつかの実装形態において、ネットワークノード１１０４のそれぞれは、ＦＥＴＣＨ＿ＥＣＨＯメッセージに含まれるシーケンス番号が、ネットワークノード１１０４と関連付けられた最も新しいシーケンス番号を超過しているかどうかを判断することによって、ＦＥＴＣＨ＿ＥＣＨＯメッセージを検証する。ＦＥＴＣＨ＿ＥＣＨＯメッセージに含まれるシーケンス番号が、ネットワークノード１１０４と関連付けられた最も新しいシーケンス番号に等しい場合、ネットワークノード１１０４は、ＦＥＴＣＨ＿ＥＣＨＯメッセージが有効であること、およびＥＣＨＯメッセージがネットワークノード１１０２に送られることになると判断する。ＦＥＴＣＨ＿ＥＣＨＯメッセージに含まれるシーケンス番号が、ネットワークノード１１０４と関連付けられた最も新しいシーケンス番号を超過する場合、ネットワークノード１１０４は、ＦＥＴＣＨ＿ＥＣＨＯメッセージが無効であるということ、およびＥＣＨＯメッセージがネットワークノード１１０２に送られることはないということを判断する。
【０１５６】
１１１８において、ネットワークノード１１０２は、ネットワークノード１１０４によって送られたＥＣＨＯメッセージが有効であるかどうかを検証する。いくつかの実装形態において、ネットワークノード１１０２は、マークル木を使用してＥＣＨＯメッセージを検証する。例えば、ネットワークノード１１０２は、ＥＣＨＯメッセージに含まれるデータを使用してマークル木を再構築し、再構築されたマークル木の再構築されたルートハッシュ値を判断することができる。ネットワークノード１１０２は、次に、再構築されたルートハッシュ値を、ＥＣＨＯメッセージに含まれるルートハッシュ値と比較することができる。再構築されたルートハッシュ値が、ＥＣＨＯメッセージに含まれるルートハッシュ値にマッチする場合、ネットワークノード１１０２は、ＥＣＨＯメッセージが有効であると判断する。再構築されたルートハッシュ値が、ＥＣＨＯメッセージに含まれるルートハッシュ値にマッチしない場合、ネットワークノード１１０２は、ＥＣＨＯメッセージが無効であると判断し、無効のＥＣＨＯメッセージを廃棄することができる。
【０１５７】
いくつかの実装形態において、ネットワークノード１１０２は、ＥＣＨＯメッセージ内の署名が有効であるかどうかをさらに検証することによって、ＥＣＨＯメッセージが有効であるかどうかを検証する。例えば、ネットワークノード１１０２は、秘密鍵とペアになる公開鍵を使用してＥＣＨＯメッセージ内の秘密鍵署名を認証して、署名を検証することができる。
【０１５８】
１１２０において、ネットワークノード１１０２は、他のネットワークノード１１０４から受け取られた有効なＥＣＨＯメッセージの数が所定の閾値を超過するかどうかを判断する。例えば、ネットワークノード１１０２は、他のネットワークノード１１０４から受け取られた有効なＥＣＨＯメッセージの数が定足数（例えば２ｆ＋１）を超過するかどうかを判断することができる。
【０１５９】
１１２２において、ネットワークノード１１０２は、有効なＥＣＨＯメッセージの数が所定の閾値を超過するとの判断に応答して、対象シーケンス番号の対象取引を回復させる。いくつかの実装形態において、ネットワークノード１１０２は、いくつかの有効なＥＣＨＯメッセージに含まれるデータを使用して対象取引を回復させる。例えば、ネットワークノード１１０２は、ＥＣコードに従って対象取引を再構築するために、ＥＣＨＯメッセージに含まれるＥＣブロックのサブセットを取得することができる。
【０１６０】
１１２４において、ネットワークノード１１０２は、対象取引を回復させた後、他のネットワークノード１１０４にＡＣＣＥＰＴメッセージをマルチキャストする。例えば、ネットワークノード１１０２は、対象取引を成功裏に再構築した後、他のネットワークノード１１０４にＡＣＣＥＰＴメッセージをマルチキャストすることができる。いくつかの実装形態において、ＡＣＣＥＰＴメッセージは、ＥＣＨＯメッセージ内の署名のセット、および対象シーケンス番号を含む。署名および対象シーケンス番号を含むＡＣＣＥＰＴメッセージを他のネットワークノード１１０４に送ることによって、ネットワークノード１１０２は、ネットワークノード１１０２が回復し、システムの最新の状態に同期したことを他のネットワークノード１１０４に示す。
【０１６１】
本明細書において上述されたような回復処理は、回復処理を実行するコンピュータの動作を改善し、ネットワークのボトルネックを緩和するのに役立つ多くの特徴を含む。例えば、本明細書における回復処理は、新しい１次ノードとして使用されるネットワークノードによって状態要求メッセージを送ること、他のネットワークノードから状態リプライメッセージを受け取ること、および他のネットワークノードからＥＣＨＯメッセージを要求するためにネットワークノードによってＦＥＴＣＨ＿ＥＣＨＯメッセージを送ること、を含む動作を含む。これらの動作は、故障しているネットワークノードの回復処理が、他の故障していないネットワークノード間のコンセンサス処理の正常動作に支障を来さないように行われる。これは、回復処理の複雑性を低減させることによって、故障しているネットワークノードを回復させるためのコンピューティングリソースおよびネットワークリソースを節約することを容易にする。
【０１６２】
図１３を参照すると、図１３は、本明細書の実装形態によるコンセンサス装置１３００のモジュールを示す図である。コンセンサスを実現するための装置１３００は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。例えば、装置１３００は、図１〜図６に示された実装形態に対応することが可能である。装置１３００は、ブロックチェーンネットワーク内の１次ノードにおいて実行されることが可能である。装置１３００は、取引要求を受け取るように構成された受信器または受信ユニット１３０２と、取引要求を使用してＥＣコードに従っていくつかの消去コード（ＥＣ）ブロックを生成するように構成された生成ユニット１３０４と、いくつかの第１のメッセージを１つまたは複数のバックアップノードにそれぞれ送るように構成された送信器または送信ユニット１３０６であって、いくつかの第１のメッセージのそれぞれが、いくつかのＥＣブロックと関連付けられた合成ハッシュ値を含む、送信器または送信ユニット１３０６と、バックアップノードのうちの少なくとも１つから少なくとも１つの第２のメッセージを受け取るようにさらに構成された受信器または受信ユニット１３０２であって、少なくとも１つの第２のメッセージが、いくつかの第１のメッセージのうちの１つ、およびいくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名を含む、受信器または受信ユニット１３０２と、バックアップノードのうちの少なくとも１つからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかを検証するように構成された検証ユニット１３０８と、有効な第２のメッセージの数が所定の閾値を超過するかどうかを判断するように構成された判断ユニット１３１０と、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて取引要求を再構築するように構成された再構築ユニット１３１２と、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを送るようにさらに構成された送信器または送信ユニット１３０６であって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送信器または送信ユニット１３０６と、バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを受け取るようにさらに構成された受信器または受信ユニット１３０２と、同一である所定の数の第３のメッセージの受領に応答して、取引要求を実行するように構成された実行ユニット１３１４と、を含む。
【０１６３】
任意選択の実装形態において、取引要求は、シーケンス番号と関連付けられる。
【０１６４】
任意選択の実装形態において、ＥＣコードに従って複数のＥＣブロックを生成することは、ＥＣコードを使用して取引要求をＥＣメッセージに変換することと、ＥＣメッセージをいくつかのＥＣブロックに分割することと、を含む。
【０１６５】
任意選択の実装形態において、いくつかのＥＣブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
【０１６６】
任意選択の実装形態において、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
【０１６７】
任意選択の実装形態において、いくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名は、いくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの秘密鍵署名を含む。
【０１６８】
任意選択の実装形態において、少なくとも１つの第２のメッセージは、いくつかのＥＣブロックのうちの少なくとも１つをさらに含む。
【０１６９】
任意選択の実装形態において、少なくとも１つの第２のメッセージが有効であるかどうかを検証することは、少なくとも１つの第２のメッセージ内のいくつかのＥＣブロックのうちの少なくとも１つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値が少なくとも１つの第２のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
【０１７０】
任意選択の実装形態において、判断ユニット１３１０は、再構築された合成ハッシュ値が第２のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも１つの第２のメッセージが有効であると判断するようにさらに構成される。
【０１７１】
任意選択の実装形態において、同一である所定の数の第３のメッセージは、署名の同一セットを有する所定の数の第３のメッセージを含む。
【０１７２】
図１３は、コンセンサス装置１３００の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
【０１７３】
少なくとも１つのプロセッサは、取引要求を受け取ることと、取引要求を使用してＥＣコードに従っていくつかの消去コード（ＥＣ）ブロックを生成することと、いくつかの第１のメッセージを１つまたは複数のバックアップノードにそれぞれ送ることであって、いくつかの第１のメッセージのそれぞれが、いくつかのＥＣブロックと関連付けられた合成ハッシュ値を含む、送ることと、バックアップノードのうちの少なくとも１つから少なくとも１つの第２のメッセージを受け取ることであって、少なくとも１つの第２のメッセージが、いくつかの第１のメッセージのうちの１つ、およびいくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名を含む、受け取ることと、バックアップノードのうちの少なくとも１つからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかを検証することと、有効な第２のメッセージの数が所定の閾値を超過するかどうかを判断することと、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて取引要求を再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを送ることであって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを受け取ることと、同一である所定の数の第３のメッセージの受領に応答して、取引要求を実行することと、を行うように構成される。
【０１７４】
任意選択で、取引要求は、シーケンス番号と関連付けられる。
【０１７５】
任意選択で、ＥＣコードに従って複数のＥＣブロックを生成することは、ＥＣコードを使用して取引要求をＥＣメッセージに変換することと、ＥＣメッセージをいくつかのＥＣブロックに分割することと、を含む。
【０１７６】
任意選択で、いくつかのＥＣブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
【０１７７】
任意選択で、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
【０１７８】
任意選択で、いくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの署名は、いくつかの第１のメッセージのうちの１つと関連付けられたバックアップノードのうちの少なくとも１つの秘密鍵署名を含む。
【０１７９】
任意選択で、少なくとも１つの第２のメッセージは、いくつかのＥＣブロックのうちの少なくとも１つをさらに含む。
【０１８０】
任意選択で、少なくとも１つの第２のメッセージが有効であるかどうかを検証することは、少なくとも１つの第２のメッセージ内のいくつかのＥＣブロックのうちの少なくとも１つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値が少なくとも１つの第２のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
【０１８１】
任意選択で、少なくとも１つのプロセッサは、再構築された合成ハッシュ値が第２のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも１つの第２のメッセージが有効であると判断するようにさらに構成される。
【０１８２】
任意選択で、同一である所定の数の第３のメッセージは、署名の同一セットを有する所定の数の第３のメッセージを含む。
【０１８３】
図１４を参照すると、図１４は、本明細書の実装形態によるコンセンサス装置１４００のモジュールを示す図である。コンセンサスを実現するための装置１４００は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置１４００は、図１〜図６に示された実装形態に対応することが可能である。例えば、装置１４００は、ブロックチェーンネットワークのバックアップノード内で実行されることが可能である。装置１４００は、１次ノードから第１のメッセージを受け取るように構成された受信器または受信ユニット１４０２であって、第１のメッセージが、いくつかのＥＣブロックと関連付けられた合成ハッシュ値を含み、いくつかのＥＣブロックが、取引要求を使用してＥＣコードに従って１次ノードによって生成される、受信器または受信ユニット１４０２と、第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージをバックアップノードによって送るように構成された送信器または送信ユニット１４０４であって、第２のメッセージが、第１のメッセージおよび第１のメッセージと関連付けられたバックアップノードの署名を含む、送信器または送信ユニット１４０４と、このバックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取るようにさらに構成された受信器または受信ユニット１４０２と、少なくとも１つのバックアップノードからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかを検証するように構成された検証ユニット１４０６と、有効な第２のメッセージの数が所定の閾値を超過するかどうかを判断するように構成された判断ユニット１４０８と、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて取引要求を再構築するように構成された再構築ユニット１４１０と、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを送るように構成された送信器または送信ユニット１４０４であって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送信器または送信ユニット１４０４と、バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを受け取るようにさらに構成された受信器または受信ユニット１４０２と、同一である所定の数の第３のメッセージの受領に応答して、取引要求を実行するように構成された実行ユニット１４１２と、を含む。
【０１８４】
任意選択の実装形態において、ＥＣコードに従って複数のＥＣブロックを生成することは、ＥＣコードを使用して取引要求をＥＣメッセージに変換することと、ＥＣメッセージをいくつかのＥＣブロックに分割することと、を含む。
【０１８５】
任意選択の実装形態において、複数のＥＣブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
【０１８６】
任意選択の実装形態において、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
【０１８７】
任意選択の実装形態において、第１のメッセージと関連付けられたバックアップノードの署名は、第１のメッセージと関連付けられたバックアップノードの秘密鍵署名を含む。
【０１８８】
任意選択の実装形態において、少なくとも１つの第２のメッセージは、いくつかのＥＣブロックのうちの少なくとも１つをさらに含む。
【０１８９】
任意選択の実装形態において、少なくとも１つの第２のメッセージが有効であるかどうかを検証することは、少なくとも１つの第２のメッセージ内のいくつかのＥＣブロックのうちの少なくとも１つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値を少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、再構築された合成ハッシュ値が少なくとも１つの第２のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
【０１９０】
任意選択の実装形態において、判断ユニット１４０８は、再構築された合成ハッシュ値が第２のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも１つの第２のメッセージが有効であると判断するようにさらに構成される。
【０１９１】
任意選択の実装形態において、同一である所定の数の第３のメッセージは、署名の同一セットを有する所定の数の第３のメッセージを含む。
【０１９２】
図１４は、コンセンサス装置１４００の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
【０１９３】
少なくとも１つのプロセッサは、１次ノードから第１のメッセージを受け取ることであって、第１のメッセージが、いくつかのＥＣブロックと関連付けられた合成ハッシュ値を含み、いくつかのＥＣブロックが、取引要求を使用してＥＣコードに従って１次ノードによって生成される、受け取ることと、第１のメッセージの受領に応答して、他のネットワークノードに第２のメッセージをバックアップノードによって送ることであって、第２のメッセージが、第１のメッセージおよび第１のメッセージと関連付けられたバックアップノードの署名を含む、送ることと、このバックアップノード以外の少なくとも１つのバックアップノードから少なくとも１つの第２のメッセージを受け取ることと、少なくとも１つのバックアップノードからの少なくとも１つの第２のメッセージの受領に応答して、少なくとも１つの第２のメッセージが有効であるかどうかを検証することと、有効な第２のメッセージの数が所定の閾値を超過するかどうかを判断することと、有効な第２のメッセージの数が所定の閾値を超過するとの判断に応答して、ＥＣコードに従っていくつかの有効な第２のメッセージのサブセットに基づいて取引要求を再構築することと、取引要求が成功裏に再構築されたとの判断に応答して、他のネットワークノードに第３のメッセージを送ることであって、第３のメッセージが、有効な第２のメッセージ内にある署名のセットを含む、送ることと、バックアップノードのうちの少なくとも１つから少なくとも１つの第３のメッセージを受け取ることと、同一である所定の数の第３のメッセージの受領に応答して、取引要求を実行することと、を行うように構成される。
【０１９４】
任意選択で、ＥＣコードに従って複数のＥＣブロックを生成することは、ＥＣコードを使用して取引要求をＥＣメッセージに変換することと、ＥＣメッセージをいくつかのＥＣブロックに分割することと、を含む。
【０１９５】
任意選択で、複数のＥＣブロックの合成ハッシュ値は、ハッシュ木を使用して生成される。
【０１９６】
任意選択で、ハッシュ木はマークル木を含み、合成ハッシュ値はマークル木のルートハッシュ値である。
【０１９７】
任意選択で、第１のメッセージと関連付けられたバックアップノードの署名は、第１のメッセージと関連付けられたバックアップノードの秘密鍵署名を含む。
【０１９８】
任意選択で、少なくとも１つの第２のメッセージは、いくつかのＥＣブロックのうちの少なくとも１つをさらに含む。
【０１９９】
任意選択で、少なくとも１つの第２のメッセージが有効であるかどうかを検証することは、少なくとも１つの第２のメッセージ内のいくつかのＥＣブロックのうちの少なくとも１つを使用して、再構築されたハッシュ木を生成することと、再構築されたハッシュ木の再構築された合成ハッシュ値を判断することと、再構築された合成ハッシュ値を少なくとも１つの第２のメッセージ内の合成ハッシュ値と比較することと、再構築された合成ハッシュ値が少なくとも１つの第２のメッセージ内の合成ハッシュ値にマッチするかどうかを判断することと、を含む。
【０２００】
任意選択で、少なくとも１つのプロセッサは、再構築された合成ハッシュ値が第２のメッセージ内の合成ハッシュ値にマッチするとの判断に応答して、少なくとも１つの第２のメッセージが有効であると判断するようにさらに構成される。
【０２０１】
任意選択で、同一である所定の数の第３のメッセージは、署名の同一セットを有する所定の数の第３のメッセージを含む。
【０２０２】
図１５を参照すると、図１５は、本明細書の実装形態による１次ノード変更装置１５００のモジュールを示す図である。１次ノードを変更するための装置１５００は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置１５００は、図７〜図９において示された実装形態に対応することが可能である。例えば、装置１５００は、ブロックチェーンネットワークのバックアップノードにおいて実行されることが可能である。装置１５００は、エポック変更が行われる必要があると判断するように構成された判断ユニット１５０２であって、エポック変更は、現在の１次ノードによる現在のエポックから、新しい１次ノードによる新しいエポックへの変更を引き起こし、現在のエポックは、１次ノードを使用していくつかのネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含み、コンセンサス処理が３つのフェーズを含む、判断ユニット１５０２と、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断するようにさらに構成された判断ユニット１５０２であって、重みが、新しい１次ノードになるためのバックアップノードの資格の測定基準である、判断ユニット１５０２と、現在のエポックにおける３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みに基づいてバックアップノードに対する加重和を判断するようにさらに構成された判断ユニット１５０２と、加重和が第１の所定の閾値に達したとの判断に応答して、このネットワークノード以外のいくつかのネットワークノードにＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを送るように構成された送信器または送信ユニット１５０４であって、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが、現在の１次ノードによる現在のエポックから、バックアップノードが新しい１次ノードである新しいエポックへの変更のための要求を示し、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージがバックアップノードの加重和を含む、送信器または送信ユニット１５０４と、このバックアップノード以外のいくつかのネットワークノードのうちの少なくとも１つから少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージを受け取るように構成された受信器または受信ユニット１５０６であって、ＮＥＷ＿ＥＰＯＣＨメッセージが、新しい１次ノードにバックアップノードがなることについての承認を示す、受信器または受信ユニット１５０６と、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証するように構成された検証ユニット１５０８と、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージからの有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が第２の所定の閾値を超過するかどうかを判断するようにさらに構成された判断ユニット１５０２と、有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が第２の所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい１次ノードであると判断するようにさらに構成された判断ユニット１５０２と、を含む。
【０２０３】
任意選択の実装形態において、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、コンセンサス処理の第１のフェーズに対するバックアップノードの重みが第１の値であると判断することを含む。
【０２０４】
任意選択の実装形態において、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第２のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第２のフェーズに対するバックアップノードの重みが第１の値であると判断することと、現在のエポックにおけるコンセンサス処理の第２のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第２のフェーズに対するバックアップノードの重みが第２の値であると判断することであって、第１の値が第２の値より小さい、判断することと、を含む。
【０２０５】
任意選択の実装形態において、ネットワークノードに対する第２のフェーズにおける定足数検証は、他のネットワークノードから所定の数のＥＣＨＯメッセージを受け取ることを含む。
【０２０６】
任意選択の実装形態において、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第３のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第３のフェーズに対するバックアップノードの重みが第３の値であると判断することと、現在のエポックにおけるコンセンサス処理の第３のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第３のフェーズに対するバックアップノードの重みが第４の値であると判断することであって、第３の値が第４の値より小さい、判断することと、を含む。
【０２０７】
任意選択の実装形態において、ネットワークノードに対する第３のフェーズにおける定足数検証は、他のネットワークノードから所定の数の受け入れメッセージを受け取ることであって、他のネットワークノードからの受け入れメッセージのそれぞれが、他のネットワークノードのそれぞれが所定の数のＥＣＨＯメッセージを受け入れたことを示す、受け取ることを含む。
【０２０８】
任意選択の実装形態において、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、いくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットをさらに含み、ＮＥＷ＿ＥＰＯＣＨメッセージは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストを含む。
【０２０９】
任意選択の実装形態において、少なくとも１つの有効なＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証することは、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
【０２１０】
任意選択の実装形態において、エポック変更が行われる必要があると判断することは、所定の期間内に古いエポックにおいてコンセンサスが実現されなかったとの判断に応答して、エポック変更が行われる必要があると判断することを含む。
【０２１１】
任意選択の実装形態において、１次ノード変更装置１５００は、新しい１次ノードによる新しいエポックにおいて動作するように構成された動作ユニット１５１０であって、新しいエポックが、新しい１次ノードを使用して複数のネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含む、動作ユニット１５１０をさらに含む。
【０２１２】
図１５は、１次ノード変更装置１５００の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
【０２１３】
少なくとも１つのプロセッサは、エポック変更が行われる必要があると判断することであって、エポック変更が、現在の１次ノードによる現在のエポックから、新しい１次ノードによる新しいエポックへの変更を引き起こし、現在のエポックが、１次ノードを使用していくつかのネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含み、コンセンサス処理が３つのフェーズを含む、判断することと、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することであって、重みが、新しい１次ノードになるためのバックアップノードの資格の測定基準である、判断することと、現在のエポックにおける３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みに基づいてバックアップノードに対する加重和を判断することと、加重和が第１の所定の閾値に達したとの判断に応答して、このネットワークノード以外のいくつかのネットワークノードにＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを送ることであって、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが、現在の１次ノードによる現在のエポックから、バックアップノードが新しい１次ノードである新しいエポックへの変更のための要求を示し、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージがバックアップノードの加重和を含む、送ることと、このバックアップノード以外のいくつかのネットワークノードのうちの少なくとも１つから少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージを受け取ることであって、ＮＥＷ＿ＥＰＯＣＨメッセージが、新しい１次ノードにバックアップノードがなることについての承認を示す、受け取ることと、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証することと、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージからの有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が第２の所定の閾値を超過するかどうかを判断することと、有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が第２の所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい１次ノードであると判断することと、を行うように構成される。
【０２１４】
任意選択で、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、コンセンサス処理の第１のフェーズに対するバックアップノードの重みが第１の値であると判断すること含む。
【０２１５】
任意選択で、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第２のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第２のフェーズに対するバックアップノードの重みが第１の値であると判断することと、現在のエポックにおけるコンセンサス処理の第２のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第２のフェーズに対するバックアップノードの重みが第２の値であると判断することであって、第１の値が第２の値より小さい、判断することと、を含む。
【０２１６】
任意選択で、ネットワークノードに対する第２のフェーズにおける定足数検証は、他のネットワークノードから所定の数のＥＣＨＯメッセージを受け取ることを含む。
【０２１７】
任意選択で、現在のエポックにおけるコンセンサス処理の３つのフェーズのそれぞれと関連付けられたバックアップノードの個々の重みを判断することは、現在のエポックにおけるコンセンサス処理の第３のフェーズにおいて定足数検証に失敗したとの判断に応答して、コンセンサス処理の第３のフェーズに対するバックアップノードの重みが第３の値であると判断することと、現在のエポックにおけるコンセンサス処理の第３のフェーズにおいて定足数検証に成功したとの判断に応答して、コンセンサス処理の第３のフェーズに対するバックアップノードの重みが第４の値であると判断することであって、第３の値が第４の値より小さい、判断することと、を含む。
【０２１８】
任意選択で、ネットワークノードに対する第３のフェーズにおける定足数検証は、他のネットワークノードから所定の数の受け入れメッセージを受け取ることであって、他のネットワークノードからの受け入れメッセージのそれぞれが、他のネットワークノードのそれぞれが所定の数のＥＣＨＯメッセージを受け入れたことを示す、受け取ることを含む。
【０２１９】
任意選択で、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、いくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットをさらに含み、ＮＥＷ＿ＥＰＯＣＨメッセージは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストを含む。
【０２２０】
任意選択で、少なくとも１つの有効なＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証することは、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することが、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
【０２２１】
任意選択で、エポック変更が行われる必要があると判断することは、所定の期間内に古いエポックにおいてコンセンサスが実現されなかったとの判断に応答して、エポック変更が行われる必要があると判断することを含む。
【０２２２】
任意選択で、少なくとも１つのプロセッサは、新しい１次ノードによる新しいエポックにおいて動作するようにさらに構成され、新しいエポックは、新しい１次ノードを使用して複数のネットワークノード間のコンセンサスを実現するためのコンセンサス処理を含む。
【０２２３】
図１６を参照すると、図１６は、本明細書の実装形態による１次ノード変更装置１６００のモジュールを示す図である。１次ノードを変更するための装置１６００は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置１６００は、図７〜図９において示された実装形態に対応する。例えば、装置１６００は、ブロックチェーンネットワークのネットワークノードにおいて実行されることが可能である。装置１６００は、このネットワークノード以外のバックアップノードからＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを受け取るように構成された受信器または受信ユニット１６０２であって、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが、エポック変更が行われる必要があるという指示を含み、エポック変更が、現在の１次ノードによる現在のエポックから、新しい１次ノードによる新しいエポックへの変更を引き起こす、受信器または受信ユニット１６０２と、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であるかどうかを検証するように構成された検証ユニット１６０４と、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であることの検証に応答して、他のネットワークノードにＮＥＷ＿ＥＰＯＣＨメッセージを送るように構成された送信器または送信ユニット１６０６であって、ＮＥＷ＿ＥＰＯＣＨメッセージが、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストを含む、送信器または送信ユニット１６０６と、このネットワークノード以外のいくつかのネットワークノードのうちの少なくとも１つから少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージを受け取るようにさらに構成された受信器または受信ユニット１６０２と、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証するようにさらに構成された検証ユニット１６０４と、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージからの有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過するかどうかを判断するように構成された判断ユニット１６０８と、有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい１次ノードであると判断するようにさらに構成された判断ユニット１６０８と、を含む。
【０２２４】
任意選択の実装形態において、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、バックアップノードと関連付けられた加重和、およびいくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットを含む。
【０２２５】
任意選択の実装形態において、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であるかどうかを検証することは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の加重和が有効であるかどうかを検証することを含み、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の加重和が有効であるかどうかを検証することは、署名のセットが有効であるかどうかを検証することを含む。
【０２２６】
任意選択の実装形態において、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証することは、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
【０２２７】
図１６は、１次ノード変更装置１６００の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
【０２２８】
少なくとも１つのプロセッサは、このネットワークノード以外のバックアップノードからＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを受け取ることであって、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが、エポック変更が行われる必要があるという指示を含み、エポック変更が、現在の１次ノードによる現在のエポックから、新しい１次ノードによる新しいエポックへの変更を引き起こす、受け取ることと、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であるかどうかを検証することと、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であることの検証に応答して、他のネットワークノードにＮＥＷ＿ＥＰＯＣＨメッセージを送ることであって、ＮＥＷ＿ＥＰＯＣＨメッセージが、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストを含む、送ることと、このネットワークノード以外のいくつかのネットワークノードのうちの少なくとも１つから少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージを受け取ることと、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証することと、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージからの有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過するかどうかを判断することと、有効なＮＥＷ＿ＥＰＯＣＨメッセージの数が所定の閾値を超過するとの判断に応答して、バックアップノードが新しいエポックにおける新しい１次ノードであると判断することと、を行うように構成される。
【０２２９】
任意選択で、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージは、バックアップノードと関連付けられた加重和、およびいくつかのネットワークノードからのネットワークノードのセットと関連付けられた署名のセットを含む。
【０２３０】
任意選択で、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージが有効であるかどうかを検証することは、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の加重和が有効であるかどうかを検証することを含み、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の加重和が有効であるかどうかを検証することは、署名のセットが有効であるかどうかを検証することを含む。
【０２３１】
任意選択で、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージが有効であるかどうかを検証することが、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することを含み、少なくとも１つのＮＥＷ＿ＥＰＯＣＨメッセージ内のＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージのダイジェストが有効であるかどうかを検証することが、ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ内の署名のセットが有効であるかどうかを検証することを含む。
【０２３２】
図１７を参照すると、図１７は、本明細書の実装形態による回復装置１７００のモジュールを示す図である。回復のための装置１７００は、ブロックチェーン技術に基づくコンセンサスシステムに使用されることが可能である。装置１７００は、図１０〜図１２において示された実装形態に対応することが可能である。例えば、装置１７００は、ブロックチェーンネットワークのネットワークノード内で実行されることが可能である。装置１７００は、ブロックチェーンネットワークのいくつかの他のネットワークノードに状態要求メッセージをブロックチェーンネットワークのネットワークノードによってブロードキャストするように構成されたブロードキャストユニット１７０２であって、ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ブロードキャストユニット１７０２と、いくつかの他のネットワークノードからいくつかの状態リプライメッセージを受け取るように構成された受信器１７０４または受信ユニット１７０４であって、いくつかの状態リプライメッセージのそれぞれがシーケンス番号を含む、受信器１７０４または受信ユニット１７０４と、状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて対象シーケンス番号を識別するように構成された識別ユニット１７０６であって、いくつかの状態メッセージのそれぞれが同じシーケンス番号を含む、識別ユニット１７０６と、いくつかの他のネットワークノードに要求メッセージを送るように構成された送信器１７０８または送信ユニット１７０８であって、要求メッセージが、いくつかの他のネットワークノードのそれぞれからのＥＣＨＯメッセージを要求し、ＥＣＨＯメッセージが、対象シーケンス番号を有する対象取引に対するいくつかの他のネットワークノード間のコンセンサスを実現するためにいくつかの他のネットワークノードのそれぞれによって送信されたメッセージであり、ＥＣＨＯメッセージが、対象取引の一部、およびいくつかの他のネットワークノードのそれぞれの署名を含む、送信器１７０８または送信ユニット１７０８と、いくつかの他のネットワークノードからいくつかのＥＣＨＯメッセージを受け取るようにさらに構成された受信器１７０４または受信ユニット１７０４と、いくつかのＥＣＨＯメッセージからいくつかの有効なＥＣＨＯメッセージを判断するように構成された判断ユニット１７１０であって、いくつかの有効なＥＣＨＯメッセージのそれぞれが対象シーケンス番号を含む、判断ユニット１７１０と、有効なＥＣＨＯメッセージの数が所定の閾値を超過するとの判断に応答して、いくつかの有効なＥＣＨＯメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させるように構成された回復ユニット１７１２と、ネットワークノードが回復されたことを示すメッセージをいくつかの他のネットワークノードに送るようにさらに構成された送信器１７０８と、を含む。
【０２３３】
任意選択の実装形態において、いくつかのネットワークノードは、１次ノードおよび１つまたは複数のバックアップノードを含む。
【０２３４】
任意選択の実装形態において、ネットワークノードは、１次ノードまたはバックアップノードである。
【０２３５】
任意選択の実装形態において、要求メッセージは、対象シーケンス番号を含む。
【０２３６】
任意選択の実装形態において、回復装置１７００は、ネットワークノードにＥＣＨＯメッセージを送る前に、要求メッセージをこのネットワークノード以外のいくつかの他のネットワークノードのそれぞれによって検証するように構成された検証ユニット１７１４をさらに含む。
【０２３７】
任意選択の実装形態において、検証ユニット１７１４は、ＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証するようにさらに構成され、ＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することは、マークル木を使用してＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することを含む。
【０２３８】
任意選択の実装形態において、ＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することは、ＥＣＨＯメッセージ内の署名が有効であるかどうかを検証することをさらに含む。
【０２３９】
任意選択の実装形態において、ＥＣＨＯメッセージのそれぞれは、対象取引と関連付けられたいくつかの消去コード（ＥＣ）ブロックのうちの少なくとも１つをさらに含み、いくつかのＥＣブロックは、対象取引を使用してＥＣコードに従って生成される。
【０２４０】
任意選択の実装形態において、いくつかの有効なＥＣＨＯメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることは、いくつかの有効なＥＣＨＯメッセージ内にある複数のＥＣブロックのサブセットを使用して対象取引を再構築することを含む。
【０２４１】
任意選択の実装形態において、ネットワークノードが回復されたことを示すいくつかの他のネットワークノードへのメッセージは、いくつかの有効なＥＣＨＯメッセージ内の署名のセット、および対象シーケンス番号を含む。
【０２４２】
以前の実装形態において示されたシステム、装置、モジュール、またはユニットは、コンピュータチップまたはエンティティを使用することによって実行されることが可能であり、また一定の機能を有する製品を使用することによって実行されることが可能である。典型的な実行デバイスはコンピュータであり、コンピュータは、パーソナルコンピュータ、ラップトップコンピュータ、セルラー電話、カメラ電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、ｅメール送受信デバイス、ゲーム機、タブレット型コンピュータ、ウェアラブルデバイス、またはこれらのデバイスの任意の組合せであることが可能である。
【０２４３】
装置内の各ユニットの機能および役割の実行処理については、以前の方法における対応するステップの実行処理に対する参照が行われることが可能である。簡略化のために詳細はここでは省略される。
【０２４４】
装置の実装形態は基本的に方法の実装形態に対応するので、関連部分については、方法の実装形態における関連説明に対する参照が行われることが可能である。前述の装置の実装形態は、１つの例にすぎない。別々の部分として説明されたユニットは、物理的に別のものであっても、そうでなくてもよく、ユニットとして表示された部分は、物理的なユニットであっても、そうでなくてもよく、１つの場所に配置されてもよく、また複数のネットワークユニット上に分散されてもよい。モジュールのいくつかまたは全ては、本明細書の解決策の目的を実現するための実際の要望に基づいて選択されることが可能である。当業者は、創造的な努力をすることなく本出願の実装形態を理解し実行することができる。
【０２４５】
図１７は、回復装置１７００の内部機能モジュールおよび構造を示す概略図である。実行体は本質的に電子デバイスであることが可能であり、電子デバイスは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサの実行可能命令を格納するように構成されたメモリと、を含む。
【０２４６】
少なくとも１つのプロセッサは、ブロックチェーンネットワークのいくつかの他のネットワークノードに状態要求メッセージをブロックチェーンネットワークのネットワークノードによってブロードキャストすることであって、ネットワークノードが、対象シーケンス番号の対象取引を回復させるためのものである、ブロードキャストすることと、いくつかの他のネットワークノードからいくつかの状態リプライメッセージを受け取ることであって、いくつかの状態リプライメッセージのそれぞれがシーケンス番号を含む、受け取ることと、状態リプライメッセージの数が所定の閾値を超過するとの判断に応答して、同じシーケンス番号に基づいて対象シーケンス番号を識別することであって、いくつかの状態メッセージのそれぞれが同じシーケンス番号を含む、識別することと、いくつかの他のネットワークノードに要求メッセージを送ることであって、要求メッセージが、いくつかの他のネットワークノードのそれぞれからのＥＣＨＯメッセージを要求し、ＥＣＨＯメッセージが、対象シーケンス番号を有する対象取引に対するいくつかの他のネットワークノード間のコンセンサスを実現するためにいくつかの他のネットワークノードのそれぞれによって送信されたメッセージであり、ＥＣＨＯメッセージが、対象取引の一部、およびいくつかの他のネットワークノードのそれぞれの署名を含む、送ることと、複数の他のネットワークノードからいくつかのＥＣＨＯメッセージを受け取ることと、いくつかのＥＣＨＯメッセージからいくつかの有効なＥＣＨＯメッセージを判断することであって、いくつかの有効なＥＣＨＯメッセージのそれぞれが対象シーケンス番号を含む、判断することと、有効なＥＣＨＯメッセージの数が所定の閾値を超過するとの判断に応答して、いくつかの有効なＥＣＨＯメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることと、ネットワークノードが回復されたことを示すメッセージをいくつかの他のネットワークノードに送ることと、を行うように構成される。
【０２４７】
任意選択で、いくつかのネットワークノードは、１次ノードおよび１つまたは複数のバックアップノードを含む。
【０２４８】
任意選択で、ネットワークノードは、１次ノードまたはバックアップノードである。
【０２４９】
任意選択で、要求メッセージは、対象シーケンス番号を含む。
【０２５０】
任意選択で、少なくとも１つのプロセッサは、ネットワークノードにＥＣＨＯメッセージを送る前に、要求メッセージをこのネットワークノード以外のいくつかの他のネットワークノードのそれぞれによって検証するようにさらに構成される。
【０２５１】
任意選択で、少なくとも１つのプロセッサは、ＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することであって、ＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することが、マークル木を使用してＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することを含む、検証すること、を行うようにさらに構成される。
【０２５２】
任意選択で、ＥＣＨＯメッセージのそれぞれが有効であるかどうかを検証することは、ＥＣＨＯメッセージ内の署名が有効であるかどうかを検証することをさらに含む。
【０２５３】
任意選択で、ＥＣＨＯメッセージのそれぞれは、対象取引と関連付けられたいくつかの消去コード（ＥＣ）ブロックのうちの少なくとも１つをさらに含み、いくつかのＥＣブロックは、対象取引を使用してＥＣコードに従って生成される。
【０２５４】
任意選択で、いくつかの有効なＥＣＨＯメッセージに基づいてネットワークノードにおいて同じシーケンス番号を有する対象取引を回復させることは、いくつかの有効なＥＣＨＯメッセージ内にあるいくつかのＥＣブロックのサブセットを使用して対象取引を再構築することを含む。
【０２５５】
任意選択で、ネットワークノードが回復されたことを示すいくつかの他のネットワークノードへのメッセージは、いくつかの有効なＥＣＨＯメッセージ内の署名のセット、および対象シーケンス番号を含む。
【０２５６】
本明細書において説明された主題の実装形態ならびにアクションおよび動作は、デジタル電子回路機器において、現実に具現化されたコンピュータソフトウェアもしくはファームウェアにおいて、本明細書およびこれらの構造上の均等物の中で開示された構造を含むコンピュータハードウェアにおいて、またはこれらの１つもしくは複数の組み合わせにおいて実行されることが可能である。本明細書において説明された主題の実装形態は、データ処理装置による実行のため、またはデータ処理装置の動作を制御するために、コンピュータプログラム担体上でエンコードされた、例えばコンピュータプログラム命令の１つまたは複数のモジュールといった、１つまたは複数のコンピュータプログラムとして実行されることが可能である。担体は、有形の非一時的コンピュータストレージ媒体であることが可能である。一方、またはさらに、担体は、データ処理装置による実行のために適切な受信装置に送信するための情報をエンコードするために生成される、例えば、機械生成された電気的、光学的、または電磁気的な信号といった、人工的に生成された伝搬信号であることが可能である。コンピュータストレージ媒体は、機械可読ストレージデバイス、機械可読ストレージ基板、ランダムもしくはシリアルアクセスメモリデバイス、またはこれらの１つもしくは複数の組合せであることが可能であり、またこれらの一部であることが可能である。コンピュータストレージ媒体は、伝搬信号ではない。
【０２５７】
用語「データ処理装置」は、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサもしくはコンピュータを例として含む、データを処理するための装置、デバイス、および機械の全ての種類を包含する。データ処理装置は、例えばＦＰＧＡ（フィールドプログラマブルゲートアレイ）、ＡＳＩＣ（特定用途向け集積回路）、またはＧＰＵ（グラフィックス処理ユニット）といった特殊用途のロジック回路機器を含むことができる。装置は、ハードウェアの他に、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの１つまたは複数の組合せを構成するコードといった、コンピュータプログラムのための実行環境を作り出すコードを含むこともできる。
【０２５８】
プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリ、モジュール、ソフトウェアモジュール、エンジン、スクリプト、もしくはコードと呼ばれること、またはこれらとして説明されることが可能なコンピュータプログラムは、コンパイルもしくは翻訳された言語、または宣言型言語もしくは手続き型言語を含む、プログラミング言語の任意の形式で書き込まれることが可能であり、コンピュータプログラムは、スタンドアロンプログラムとして、あるいはモジュール、コンポーネント、エンジン、サブルーチン、または１つもしくは複数の場所においてデータ通信ネットワークによって相互接続された１つもしくは複数のコンピュータを含むことができるコンピューティング環境における実行に適した他のユニットとして含む、任意の形式で導入されることが可能である。
【０２５９】
コンピュータプログラムは、ファイルシステムにおけるファイルに対応することができるが、そうである必要はない。コンピュータプログラムは、例えば、マークアップ言語文書に、当該のプログラムに専用の単一のファイルに、または例えば、１つもしくは複数のモジュール、サブプログラム、もしくはコードの一部を格納するファイルといった、複数のコーディネイテッドファイルに格納された１つまたは複数のスクリプトといった、他のプログラムまたはデータを保持するファイルの一部に格納されることが可能である。
【０２６０】
本明細書において説明された処理およびロジックフローは、１つまたは複数のコンピュータプログラムを実行して、入力データに対して演算し、出力を生成することによって動作を行う、１つまたは複数のコンピュータによって行われることが可能である。処理およびロジックフローは、例えば、ＦＰＧＡ、ＡＳＩＣ、もしくはＧＰＵといった特殊用途のロジック回路機器によって、または特殊用途のロジック回路機器および１つもしくは複数のプログラムされたコンピュータの組合せによって行われることも可能である。
【０２６１】
コンピュータプログラムの実行に適したコンピュータは、汎用もしくは特殊用途のマイクロプロセッサまたは両方、あるいは他の任意の種類の中央処理装置に基づくことが可能である。一般に、中央処理装置は、リードオンリメモリもしくはランダムアクセスメモリまたは両方から命令およびデータを受け取ることになる。コンピュータの要素は、命令を実行するための中央処理装置、ならびに命令およびデータを格納するための１つまたは複数のメモリデバイスを含むことができる。中央処理装置およびメモリは、特殊用途のロジック回路機器によって補われることも、特殊用途のロジック回路機器に組み込まれることも可能である。
【０２６２】
一般に、コンピュータは、（コンピュータ可読メモリとも呼ばれる）少なくとも１つの非一時的コンピュータ可読ストレージ媒体に連結されることになる。コンピュータに連結されたストレージ媒体は、コンピュータの内部構成要素（例えば統合されたハードドライブ）、または外部構成要素（例えば、ユニバーサルシリアルバス（ＵＳＢ）ハードドライブもしくはネットワークを超えてアクセスされるストレージシステム）であることが可能である。ストレージ媒体の例は、例えば、磁気ディスク、光磁気ディスク、もしくは光ディスク、ソリッドステートデバイス、クラウドストレージシステムなどのネットワークストレージリソース、またはストレージ媒体の他のタイプを含むことができる。しかし、コンピュータは、このようなデバイスを有する必要はない。さらに、コンピュータは、例えば、ほんの数例を挙げれば、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、モバイルオーディオプレーヤもしくはモバイルビデオプレーヤ、ゲーム機、全地球測位システム（ＧＰＳ）受信器、または例えばユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブといった携帯型ストレージデバイスといった、別のデバイスに組み込まれることが可能である。
【０２６３】
ユーザとの対話を行うために、本明細書において説明された主題の実装形態は、ユーザに情報を表示するための例えばＬＣＤ（液晶ディスプレイ）モニタといった表示デバイス、ならびに例えばキーボード、および例えばマウス、トラックボールもしくはタッチパッドといったポインティングデバイスといった、ユーザがコンピュータに入力することができる入力デバイスを有するコンピュータ上で実行されること、またはこのコンピュータと通信するように構成されることが可能である。同様にユーザとの対話を行うために他の種類のデバイスが使用されることが可能であり、例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックといった、知覚によるフィードバックの任意の形式であることが可能であり、ユーザからの入力は、音響、会話、または触知入力を含む任意の形式で受け取られることが可能である。さらに、コンピュータは、例えば、ウェブブラウザから受け取られた要求に応答して、ユーザのデバイス上のウェブブラウザにウェブページを送ることによって、または例えばスマートフォンもしくは電子タブレットといったユーザデバイス上で動くアプリと対話することによって、ユーザによって使用されるデバイスとの間で文書をやりとりすることによってユーザと対話することができる。同様に、コンピュータは、例えば、メッセージングアプリケーションを動かしているスマートフォンといった個人のデバイスにテキストメッセージまたは他の形式のメッセージを送ること、および返信としてユーザから応答メッセージを受け取ることによって、ユーザと対話することができる。
【０２６４】
本明細書は、システム、装置、およびコンピュータプログラム構成要素に関連して用語「ように構成される（ｃｏｎｆｉｇｕｒｅｄ  ｔｏ）」を使用する。１つまたは複数のコンピュータのシステムが特定の動作またはアクションを行うように構成されることは、動作中に動作またはアクションをシステムに行わせる、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せをシステムがシステム上にインストールしたということを意味する。１つまたは複数のコンピュータプログラムが特定の動作またはアクションを行うように構成されることは、データ処理装置によって実行されると、動作またはアクションを装置に行わせる命令を１つまたは複数のプログラムが含むということを意味する。特殊用途のロジック回路機器が特定の動作またはアクションを行うように構成されることは、動作またはアクションを行う電子ロジックを回路機器が有するということを意味する。
【０２６５】
本明細書は、多くの特定の実装形態の詳細を収めるが、これらは、特許請求の範囲自体によって定義される特許請求されるものの範囲を限定するものと解釈されるべきではなく、むしろ特定の実装形態に固有であることが可能な特徴の説明として解釈されるべきである。別々の実装形態の背景において本明細書において説明される一定の特徴は、単一の実装形態における組み合わせの中で実現されることも可能である。逆に、単一の実装形態の背景において説明される様々な特徴は、複数の実装形態において別々に、または任意の適切なサブコンビネーションにおいて実現されることも可能である。さらに、特徴は、一定の組合せにおいて作用するものとして上述されることがあり、したがって最初であったとしても特許請求されることがあるが、特許請求される組合せからの１つまたは複数の特徴は、いくつかのケースにおいて、組合せから削除されることが可能であり、特許請求の範囲は、サブコンビネーションまたはサブコンビネーションの変形形態を対象とすることが可能である。
【０２６６】
同様に、特定の順序で、図面において動作が描写され、特許請求の範囲において列挙されるが、これは、示された特定の順序で、もしくは連続した順序でこのような動作が行われること、または全ての図示された動作が望ましい結果を実現するために行われることが必要であるとみなされるべきではない。一定の状況において、マルチタスク処理および並列処理が有利なこともある。さらに、上述の実装形態における様々なシステムモジュールおよび構成要素の分離は、全ての実装形態においてこのような分離が必要であるとみなされるべきではなく、説明されたプログラム構成要素およびシステムは、全体的に、単一のソフトウェア製品に相互に統合されることも、複数のソフトウェア製品にパッケージ化されることも可能であるということを理解されたい。
【０２６７】
主題の特定の実装形態が説明された。他の実装形態は、以下の特許請求の範囲の範囲内にある。例えば、特許請求の範囲において列挙されるアクションは、様々な順序で行われることが可能であり、依然として望ましい結果を実現する。１つの例として、添付の図において描写された処理は、望ましい結果を実現するために、示された特定の順序、または連続した順序を必ずしも必要としない。いくつかのケースにおいて、マルチタスク処理および並列処理が有利なこともある。
【符号の説明】
【０２６８】
１００  環境、システム
１０２  コンソーシアムブロックチェーンネットワーク、ブロックチェーンネットワーク
１０６  コンピューティングデバイスまたはシステム
１０８  コンピューティングデバイスまたはシステム
１１０  ネットワーク
２００  概念アーキテクチャ、システム
２０２  参加者システム
２０４  参加者システム
２０６  参加者システム
２１２  ブロックチェーンネットワーク
２１４  ノード
２１６  ブロックチェーン
２１６’  完全コピー
２１６’’  完全コピー
２１６’’’  完全コピー
３００  処理、コンセンサス処理、システム
３１０  ステージ、第１のフェーズ、フェーズ１：  ＩＮＩＴＩＡＬメッセージ
３２０  ステージ、第２のフェーズ、フェーズ２：  ＥＣＨＯメッセージ
３３０  ステージ、第３のフェーズ、フェーズ３：  ＡＣＣＥＰＴメッセージ
４００  処理、コンセンサス処理
４０２  クライアントノード
４０４  １次ノード、ノード
４０６  バックアップノード
４０８  取引要求を生成する
４１０  取引要求
４１２  ＥＣブロックを生成する
４１４  ＩＮＩＴＩＡＬメッセージを生成する
４１６  ＩＮＩＴＩＡＬメッセージ
４１８  ＥＣＨＯメッセージを生成する
４２０  ＥＣＨＯメッセージ
４２１  他のバックアップノードにＥＣＨＯメッセージを送る
４２２  ＥＣＨＯメッセージを検証する
４２３  他のバックアップノードからＥＣＨＯメッセージを受け取る
４２４  有効なＥＣＨＯメッセージを判断する
４２６  取引要求を再構築する
４２８  ＡＣＣＥＰＴメッセージを生成する
４３０  ＡＣＣＥＰＴメッセージ
４３２  ＡＣＣＥＰＴメッセージを生成する
４３４  ＡＣＣＥＰＴメッセージ
４３６  取引要求を実行する
４３８  取引結果
５００  ハッシュ木
５０２  取引要求
５０４  ＥＣコード
５０６  ＥＣメッセージ
５０８  ＥＣブロック、ＥＣブロックＡ
５０８  ＥＣブロック、ＥＣブロックＢ
５０８  ＥＣブロック、ＥＣブロックＣ
５０８  ＥＣブロック、ＥＣブロックＤ
５１０  葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュＡ
５１０  葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュＢ
５１０  葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュＣ
５１０  葉ノード、ハッシュ、暗号学的ハッシュ、ハッシュＤ
５１２  非葉ノード、ハッシュ、ハッシュＡＢ
５１２  非葉ノード、ハッシュ、ハッシュＣＤ
５１４  非葉ノード、ルートハッシュ、ハッシュＡＢＣＤ
７００  方法、処理
８００  処理
８０２  バックアップノード
８０４  他のネットワークノード、ネットワークノード
８０６  エポック変更を判断する
８０８  個々の重みを判断する
８１０  加重和を判断する
８１２  ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージ
８１４  ＥＰＯＣＨ＿ＣＨＡＮＧＥメッセージを検証する
８１６  ＮＥＷ＿ＥＰＯＣＨメッセージ
８１８  ＮＥＷ＿ＥＰＯＣＨメッセージを検証する
８２０  有効なＮＥＷ＿ＥＰＯＣＨメッセージを判断する
８２２  新しい１次ノードを判断する
１０００  処理
１０１０  第１のフェーズ、ＱＵＥＲＹ＿ＳＴＡＴＥメッセージ
１０２０  第２のフェーズ、ＲＥＰＬＹ＿ＳＴＡＴＥメッセージ
１０３０  第３のフェーズ、ＦＥＴＣＨ＿ＥＣＨＯメッセージ
１０４０  第４のフェーズ、ＥＣＨＯメッセージ
１０５０  第５のフェーズ、ローカル消去コード
１０６０  第６のフェーズ、ＡＣＣＥＰＴメッセージ
１１００  処理、方法
１１０２  ネットワークノード
１１０４  ネットワークノード
１１０６  状態要求メッセージ
１１０８  状態リプライメッセージ
１１１０  状態リプライメッセージの数を判断する
１１１２  対象シーケンス番号を識別する
１１１４  ＦＥＴＣＨ＿ＥＣＨＯメッセージ
１１１６  ＥＣＨＯメッセージ
１１１８  ＥＣＨＯメッセージを検証する
１１２０  有効なＥＣＨＯメッセージを判断する
１１２２  対象取引を回復させる
１１２４  ＡＣＣＥＰＴメッセージ
１３００  コンセンサス装置、装置
１３０２  受信器、受信ユニット
１３０４  生成ユニット
１３０６  送信器、送信ユニット
１３０８  検証ユニット
１３１０  判断ユニット
１３１２  再構築ユニット
１３１４  実行ユニット
１４００  コンセンサス装置、装置
１４０２  受信器、受信ユニット
１４０４  送信器、送信ユニット
１４０６  検証ユニット
１４０８  判断ユニット
１４１０  再構築ユニット
１４１２  実行ユニット
１５００  １次ノード変更装置、装置
１５０２  判断ユニット
１５０４  送信器、送信ユニット
１５０６  受信器、受信ユニット
１５０８  検証ユニット
１５１０  動作ユニット
１６００  １次ノード変更装置、装置
１６０２  受信器、受信ユニット
１６０４  検証ユニット
１６０６  送信器、送信ユニット
１６０８  判断ユニット
１７００  回復装置、装置
１７０２  ブロードキャストユニット
１７０４  受信器、受信ユニット
１７０６  識別ユニット
１７０８  送信器、送信ユニット
１７１０  判断ユニット
１７１２  回復ユニット
１７１４  検証ユニット
【図１】
0006803991.tif 000002
【図２】
0006803991.tif 000003
【図３】
0006803991.tif 000004
【図４】
0006803991.tif 000005
【図５】
0006803991.tif 000006
【図６】
0006803991.tif 000007
【図７】
0006803991.tif 000008
【図８】
0006803991.tif 000009
【図９】
0006803991.tif 000010
【図１０】
0006803991.tif 000011
【図１１】
0006803991.tif 000012
【図１２】
0006803991.tif 000013
【図１３】
0006803991.tif 000014
【図１４】
0006803991.tif 000015
【図１５】
0006803991.tif 000016
【図１６】
0006803991.tif 000017
【図１７】
0006803991.tif 000018