特表 2023-554090 ブロックグループヘッダの取得方法及び装置、記憶媒体、並びに電子装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-12-26

(54)【発明の名称】ブロックグループヘッダの取得方法及び装置、記憶媒体、並びに電子装置

(51)【国際特許分類】

   H04L 9/32 20060101AFI20231219BHJP

【ＦＩ】

H04L9/32 200Z

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023537119

(86)(22)【出願日】2021-11-04

(85)【翻訳文提出日】2023-06-16

(86)【国際出願番号】 CN2021128716

(87)【国際公開番号】W WO2022127424

(87)【国際公開日】2022-06-23

(31)【優先権主張番号】202011488871.4

(32)【優先日】2020-12-16

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】曾鳴

(72)【発明者】

【氏名】郭海生

(72)【発明者】

【氏名】王徳政

(72)【発明者】

【氏名】劉亜森

(72)【発明者】

【氏名】李揮

(72)【発明者】

【氏名】王▲ハン▼

(72)【発明者】

【氏名】白永杰

(72)【発明者】

【氏名】王子賢

(72)【発明者】

【氏名】呂▲チィ▼

(57)【要約】

ブロックグループヘッダの取得方法及び装置、記憶媒体、並びに電子装置を開示する。当該方法は、ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するステップであって、予め設定された条件は、ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及びターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示すステップ（Ｓ４０２）と、ターゲットノードがブロックグループヘッダを受信していないと決定した場合、ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定するステップであって、イベント原因は、ターゲットノードがブロックグループヘッダを正常に受信していないこと、及びブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含むステップ（Ｓ４０４）と、イベント原因に基づいて、ターゲットノードの、受信していないブロックグループヘッダに対する取得方式を決定するステップ（Ｓ４０６）と、を含む。
【選択図】図４

【特許請求の範囲】

【請求項1】

ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するステップであって、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示すステップと、
前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定するステップであって、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含むステップと、
前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するステップと、を含む、ブロックグループヘッダの取得方法。

【請求項2】

前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するステップは、
前記イベント原因が、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないことを示している場合、前記ブロックチェーンシステムの投票ノードから、正常に受信していない前記ブロックグループヘッダを同期して取得するステップを含む、請求項１に記載のブロックグループヘッダの取得方法。

【請求項3】

前記ブロックチェーンシステムの投票ノードから、正常に受信していない前記ブロックグループヘッダを同期して取得するステップは、
前記ブロックチェーンシステムから投票ノードを確認するステップであって、前記投票ノードのブロックチェーン高さが前記ターゲットノードのブロックチェーン高さよりも高く、前記ブロックチェーン高さはブロック高さを示すステップと、
前記投票ノードから前記ターゲットノードのブロックチェーン高さよりも高い前記ブロックグループヘッダを同期して取得するステップと、を含む、請求項２に記載のブロックグループヘッダの取得方法。

【請求項4】

前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するステップは、
前記イベント原因が、前記ブロックチェーンシステムがブロックグループヘッダを生成していないことを示している場合、受信したブロックに投票するように投票ノードに指示し、受信していない正当なブロックの処理結果を目標値に設定して、前記投票ノードが前記受信していない正当なブロックに対して意見を持たないことを示し、前記投票ノードの投票結果を得るステップと、
前記投票結果をラウンドロビン記帳ノードに送信し、前記生成されていない正当なブロックグループヘッダを生成するように前記ラウンドロビン記帳ノードに指示するステップと、を含む、請求項１に記載のブロックグループヘッダの取得方法。

【請求項5】

【請求項6】

前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するステップの後に、
前記受信していないブロックグループヘッダが正常に生成された場合、正常に生成されたブロックグループヘッダを前記ブロックチェーンシステムのすべてのノードにブロードキャストするようにラウンドロビン記帳ノードに指示し、前記正常に取得されたブロックグループヘッダを検証し、検証を通過した場合に前記正常に生成されたブロックグループヘッダを受信するようにすべてのノードに指示するステップをさらに含む、請求項１に記載のブロックグループヘッダの取得方法。

【請求項7】

ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するステップの後に、
前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないと決定した場合、前記ブロックチェーンシステムにおける他のノードに取得要求を送信するステップであって、前記取得要求は、前記他のノードから前記正当なブロックを取得するために使用され、前記他のノードは、前記ブロックチェーンシステムにおける前記ターゲットノード以外のノードであり、前記正当なブロックを保存しているステップをさらに含む、請求項１に記載のブロックグループヘッダの取得方法。

【請求項8】

ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するように構成されている第１決定モジュールであって、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示す第１決定モジュールと、
前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定するように構成されている第２決定モジュールであって、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む第２決定モジュールと、
前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するように構成されている第３決定モジュールと、を含む、ブロックグループヘッダの取得装置。

【請求項9】

実行されると、上記請求項１～７のいずれか１項に記載の方法を実行するプログラムを記憶したコンピュータ読み取り可能な記憶媒体。

【請求項10】

メモリと、プロセッサとを含む電子装置であって、
前記メモリにはコンピュータプログラムが記憶されており、
前記プロセッサは、前記コンピュータプログラムによって、前記請求項１～７のいずれか１項に記載の方法を実行するように構成されている、電子装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、出願番号が２０２０１１４８８８７１．４、出願日が２０２０年１２月１６日の中国特許出願に基づいて提出され、当該中国特許出願の優先権を主張しており、当該中国特許出願の全ての内容はここで引用により本願に組み込まれている。

【0002】

本発明は、通信分野に関し、具体的には、ブロックグループヘッダの取得方法及び装置、記憶媒体、並びに電子装置に関する。

【背景技術】

【0003】

ブロックチェーンシステムは、履歴が追跡可能で改ざん不可能で、多国間の相互信頼の問題を解決する分散型システムである。分散型システムは必然的に一致性の問題に直面し、すなわち、コンセンサスを達成する必要がある。分散型システムのコンセンサスを達成するには、信頼できるコンセンサスアルゴリズムが必要である。一般的なコンセンサスアルゴリズムには、プルーフオブワークコンセンサスアルゴリズム、実用的ビザンチン・フォールトトレラント・アルゴリズム、並行投票証明アルゴリズムなどがある。

【0004】

並行投票証明（Ｐａｒａｌｌｅｌ Ｐｒｏｏｆ ｏｆ Ｖｏｔｅ、略してＰＰｏＶ）コンセンサスアルゴリズムでは、ブロックチェーンノードを記帳ノード、投票ノード、及びリーダノードに分ける。各記帳ノードはブロックを生成してネットワークに公開し、投票ノードは記帳ノードによって生成されたブロックを収集して投票を行い、その後、投票情報を集約してリーダノードに送信する。リーダノードは集約された投票情報を収集して統計し、統計結果をブロックグループヘッダに書き込み、最後にブロックグループヘッダはネットワークに公開される。

【0005】

しかし、ＰＰｏＶコンセンサスアルゴリズムでは、ブロックグループヘッダを生成する過程で、少数の記帳ノードが故障すると、投票ノードは十分なブロックを収集できないので投票操作を行うことができず、リーダノードは投票ノードから送信されてきた投票情報を収集できないのでブロックグループヘッダを生成することができない。

【0006】

いくつかの技術案に関しては、並行投票証明ＰＰｏＶコンセンサスアルゴリズムでは、ブロックグループヘッダを取得する過程で取得率が低いなどの問題について、現在で有効な解決策がまだ提出されていない。

【発明の概要】

【発明が解決しようとする課題】

【0007】

本発明の実施例は、並行投票証明ＰＰｏＶコンセンサスアルゴリズムでは、ブロックグループヘッダを取得する過程で取得率が低いなどの問題を含め、関連する技術的課題の少なくとも１つをある程度解決するために、ブロックグループヘッダの取得方法及び装置、記憶媒体、並びに電子装置を提供する。

【課題を解決するための手段】

【0008】

本発明の実施例の一態様によれば、ブロックグループヘッダの取得方法を提供する。前記ブロックグループヘッダの取得方法は、
ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するステップであって、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示すステップと、
前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定するステップであって、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含むステップと、
前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するステップと、を含む。

【0009】

本発明の実施例の別の態様によれば、ブロックグループヘッダの取得装置をさらに提供する。前記ブロックグループヘッダの取得装置は、
ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するように構成されている第１決定モジュールであって、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示す第１決定モジュールと、
前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定するように構成されている第２決定モジュールであって、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む第２決定モジュールと、
前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するように構成されている第３決定モジュールと、を含む。

【0010】

本発明の実施例のさらに別の態様によれば、コンピュータ読み取り可能な記憶媒体をさらに提供する。前記コンピュータ読み取り可能な記憶媒体は、実行されると、上記ブロックグループヘッダの取得方法を実行するプログラムを記憶した。

【0011】

本発明の実施例のさらに別の態様によれば、電子機器をさらに提供する。前記電子機器は、メモリと、プロセッサと、メモリに記憶されてプロセッサ上で実行可能なコンピュータプログラムとを含み、上記プロセッサは、コンピュータプログラムによって、上記ブロックグループヘッダの取得方法を実行する。

【0012】

本明細書に記載された図面は、本発明の更なる理解を提供するために使用され、本願の一部を構成する。本発明の例示的な実施例及びその説明は、本発明を説明するために使用され、本発明の不当な限定を構成するものではない。

【図面の簡単な説明】

【0013】

【図1】本発明の実施例に係るブロックグループヘッダの取得方法のコンピュータ端末のハードウェア構成のブロック図である。

【図2】本発明の実施例に係るＰｏＶコンセンサス過程のメッセージ伝達の概略図である。

【図3】本発明の実施例に係るＰＰｏＶコンセンサス過程の概略図である。

【図4】本発明の実施例に係るブロックグループヘッダの取得方法のフローチャートである。

【図5】本発明の実施例に係るブロックチェーンノードのタイムアウトトリガ条件の概略図である。

【図6】本発明の実施例に係るブロックチェーンノードのタイムアウト処理モジュールの構造図である。

【図7】本発明の実施例に係るブロックチェーンノードのタイムアウト処理のフローチャートである。

【図8】本発明の実施例に係るブロックグループヘッダの取得装置の構造ブロック図である。

【発明を実施するための形態】

【0014】

当業者が本発明をより良く理解できるようにするために、以下では、本発明の実施例の図面を参照して、本発明の実施例の技術案について明確かつ完全に説明するが、説明される実施例は、本発明の一部の実施例にすぎず、全ての実施例ではないことは明らかである。本発明の実施例に基づいて、当業者が創造的な努力を必要とせずに取得した他のすべての実施例は、本発明の保護範囲に属するべきである。

【0015】

なお、本発明の明細書及び特許請求の範囲、並びに上記の図面における「第１」、「第２」等の用語は、類似の対象を区別するためのものであり、特定の順序又は優先順位を説明するためのものではない。このように使用されるデータは、本明細書に記載された本発明の実施例が本明細書に図示又は記載されたもの以外の順序で実施されることを可能にするために、適宜交換されてもよい。さらに、「含む」及び「有する」という用語、ならびにそれらの任意の変形は、非排他的な包含をカバーすることを意図しており、例えば、一連のステップ又はユニットを含む過程、方法、システム、製品、又は機器は、明示的にリストされたステップ又はユニットに限定される必要はなく、明示的にリストされていない、又はこれらの過程、方法、製品、又は機器に固有の他のステップ又はユニットを含んでもよい。

【0016】

本願の実施例で提供される方法の実施例は、コンピュータ端末又は類似の演算装置で実行することができる。コンピュータ端末で実行する場合を例として、図１は、本発明の実施例に係るブロックグループヘッダの取得方法のコンピュータ端末のハードウェア構成ブロック図である。図１に示すように、コンピュータ端末は、１つ又は複数の（図１には１つのみが示されている）プロセッサ１０２（プロセッサ１０２は、マイクロプロセッサＭＣＵ又はプログラマブルロジックデバイスＦＰＧＡなどの処理装置を含んでもよいが、これらに限定されない）と、データを記憶するメモリ１０４とを含んでもよい。一実施例では、上記コンピュータ端末は、通信機能のための伝送機器１０６及び入出力機器１０８を含んでもよい。図１に示す構成は概略的なものにすぎず、上記のコンピュータ端末の構成を限定するものではない。例えば、コンピュータ端末は、図１に示されたものよりも多く又は少ないコンポーネントを含んだり、図１に示されたものと同等の機能を有するか、又はそれよりも多くの異なる構成を有したりしてもよい。

【0017】

メモリ１０４は、コンピュータプログラム、例えば、アプリケーションソフトウェアのソフトウェアプログラム及びモジュール、例えば、本発明の実施例におけるブロックグループヘッダの取得方法に対応するコンピュータプログラムを記憶するために使用されてもよい。プロセッサ１０２は、メモリ１０４に記憶されたコンピュータプログラムを実行することによって、様々な機能アプリケーション及びデータ処理を実行し、すなわち、上記の方法を実現する。メモリ１０４は、高速ランダムアクセスメモリを含んでもよく、さらに、１つ又は複数の磁気記憶装置、フラッシュメモリ、又は他の不揮発性固体メモリのような不揮発性メモリを含んでもよい。いくつかの例では、メモリ１０４は、プロセッサ１０２に対してリモートに配置されたメモリをさらに含んでもよく、これらのリモートメモリは、ネットワークを介してコンピュータ端末に接続されることができる。上記のネットワークの例には、インターネット、企業イントラネット、ローカルエリアネットワーク、移動通信ネットワーク、及びこれらの組み合わせが含まれるが、これらに限定されない。

【0018】

伝送機器１０６は、ネットワークを介してデータを受信又は送信するためのものである。上記のネットワークの具体例は、コンピュータ端末の通信ベンダによって提供される無線ネットワークを含んでもよい。一実施例では、伝送機器１０６は、ネットワークインターフェースコントローラ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ、略してＮＩＣ）を含み、ネットワークインターフェースコントローラは、基地局を介して他のネットワーク機器に接続されて、インターネットと通信することができる。一実施例では、伝送機器１０６は、インターネットと無線で通信するための無線周波数（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ、略してＲＦ）モジュールであってもよい。

【0019】

【0020】

【0021】

多くのコンセンサスアルゴリズムと同様に、ＰｏＶコンセンサスアルゴリズムはコンセンサス周期ごとに複数の候補ノードの中から１つのノードを記帳ノードとして選択してブロックを生成するため、ブロックを生成する過程が逐次的に行われ、大規模クラスタ環境での高いスループット性能をサポートすることが困難である。

【0022】

ＰｏＶの性能を高めるために、ＰＰｏＶコンセンサスアルゴリズムは並列化に基づいてブロックグループの概念を提案した。ブロックグループは、現在のブロックグループの高さと投票結果を含むブロックグループヘッダと、投票によるすべてのブロックの集合を含むブロックグループボディと、からなる。ここで、各ブロックには、前のブロックグループのｈａｓｈ値、マークル根、生成者の公開鍵、タイムスタンプなどの情報とトランザクションの集合が含まれている。分かりやすくするために、ＰＰｏＶコンセンサスでは、一般的にブロックチェーンノードのアイデンティティを投票ノード、記帳ノード、及びリーダノードとそれぞれ表現している。図３は、本発明の実施例に係るＰＰｏＶコンセンサス過程の概略図であり、各ラウンドのＰＰｏＶコンセンサスは以下のステップで構成される。

【0023】

Ｓ１：各記帳ノードは１つのブロックを生成して、ネットワークに公開する。各ブロックチェーンノードは、すべての記帳ノードによって生成されたブロックを収集する。

【0024】

Ｓ２：投票ノードは、Ｓ１で記帳ノードによって生成されたブロックの収集を終了すると、ブロックごとに個別に投票して１つの総投票メッセージを生成してリーダノードに送信する。投票メッセージには、ブロックごとのｈａｓｈ値、同意するか否かの意見や署名などの情報が含まれる。

【0025】

Ｓ３：リーダノードは、投票ノードから送信してきた投票メッセージを収集し、投票結果を統計する。各ブロックの賛成意見又は反対意見が投票ノード数の半分を超えることを満たしている場合、統計結果及びすべての投票メッセージをブロックグループヘッダに格納する。次に、リーダノードは、次のラウンドのコンセンサス周期のリーダノード番号である乱数を生成し、それをブロックグループヘッダに書き込む。その後、ブロックグループヘッダをネットワークに公開する。

【0026】

Ｓ４：ブロックチェーンノードは、すべての記帳ノードによって生成されたブロック及びリーダノードによって生成されたブロックグループヘッダを受信すると、これらを１つのブロックグループとしてデータベースに記憶する。

【0027】

しかし、現在のところ、ＰＰｏＶコンセンサスアルゴリズムの設計は十分ではない。現実の環境の下でサーバが各種の原因で故障して正常に動作できないことを考慮して、マルチノード並列記帳の場合には、従来のＰＰｏＶコンセンサスアルゴリズムでは、その中の少量の記帳ノードの故障により、他の正常なノードが生成するブロックも検証を通過して生成することができない場合がある。すなわち、従来のＰＰｏＶコンセンサスアルゴリズムは、何らかの原因でブロックグループヘッダを生成することができず、終止可能性を満たせないことがある。

【0028】

上記の技術的課題を解決するために、本実施例では、ブロックグループヘッダの取得方法を提供する。図４は、本発明の実施例に係るブロックグループヘッダの取得方法のフローチャートであり、この流れは以下のステップを含む。

【0029】

ステップＳ４０２：ブロックチェーンシステムにおけるターゲットノードが、予め設定された条件を満たしているか否かを決定し、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示す。

【0030】

ステップＳ４０４：前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定し、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む。

【0031】

ステップＳ４０６：前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定する。

【0032】

上記ステップにより、ブロックチェーンシステムのターゲットノードが予め設定された条件を満たしているか否かを決定する。その予め設定された条件は、ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していない場合と、ターゲットノードがブロックグループヘッダを受信していない場合との２つの場合がある。２つの異なるポリシーはこの２つの場合に応じてそれぞれ設定される。ブロックグループヘッダを受信していない場合、ブロックグループヘッダを受信していないイベント原因を決定し、次に、前記イベント原因に基づいて、ターゲットノードが受信していないブロックグループヘッダをどのように取得するかを決定する。上記の技術案を採用して、並行投票証明ＰＰｏＶコンセンサスアルゴリズムではブロックグループヘッダを取得する過程において取得率が低いなどの問題を解決し、さらにブロックグループヘッダを取得する際に、異なるイベント原因に応じた取得方式を採用する。これによって、ブロックグループヘッダの取得率を高める。

【0033】

ＰＰｏＶコンセンサスアルゴリズムのコンセンサス終了条件は、ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していない条件１、及びターゲットノードがブロックグループヘッダを受信していない条件２を満たすことである。ブロックチェーンシステムにおけるターゲットノードは、予め設定された条件を満たしているか否かを判断する。満たしていない場合、タイムアウトをトリガし、前記ターゲットノードは、関連するタイムアウト操作を行う。前記ターゲットノードがブロックグループヘッダを受信していない場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定する。前記イベント原因は、前記ターゲットノードがブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む。その後、ブロックチェーンシステムは、前記イベント原因に基づいて、ターゲットノードが受信していないブロックグループヘッダをどのように取得するかを決定する。例えば、ブロックチェーンシステムのある記帳ノードＡはブロックグループヘッダを受信していないので、記帳ノードＡはタイムアウト操作をトリガして、すべての投票ノードにそのブロックチェーン高さを要求し、ローカルで各投票ノードのオンライン状態を維持する。ブロックチェーン高さが記帳ノードＡのローカルブロックチェーン高さよりも高い投票ノードが存在すれば、記帳ノードＡがブロックグループヘッダを正常に受信していないことを示している。もし見つからなければ、ブロックチェーンシステムはブロックグループヘッダを生成していないことを示している。その後、記帳ノードＡは、前記イベント原因に基づいて、取得方式を決定する。

【0034】

一方、上記のステップＳ４０６には、複数の実施形態がある。一実施例では、前記イベント原因に基づいて、前記ターゲットノードの受信していない前記ブロックグループヘッダに対する取得方式を決定するステップは、前記イベント原因が、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないことを示している場合、前記ブロックチェーンシステムの投票ノードから、正常に受信していない前記ブロックグループヘッダを同期して取得するステップを含む。本実施例では、ターゲットノードがブロックグループヘッダを受信していない場合、ターゲットノードは、前記ブロックグループヘッダを取得するように投票ノードに要求する。投票ノードは、ブロックチェーンネットワークのコアコンセンサスポイントであるため、最新のブロックチェーン状態を有すると考えられる。システムがブロックグループヘッダを生成した場合、生成されたブロックグループヘッダがブロックチェーンネットワークにブロードキャストされる間、投票ノードは必ずそれを受信する。例えば、記帳ノードＡがブロックグループヘッダを受信していない場合、記帳ノードＡは、投票ノードＢにデータ同期化を行い、ブロックグループヘッダを取得し、ここで、投票ノードＢのブロックチェーン高さは記帳ノードＡよりも高い。

【0035】

いくつかの例では、ブロックチェーンシステムの投票ノードから正常に受信していない前記ブロックグループヘッダを同期して取得する過程において、ローカル記帳ノードのブロックチェーン高さよりも高い投票ノードからブロックグループを取得する必要があり、前記ブロックチェーン高さはブロック高さを示すために使用される。本実施例では、前記ブロックチェーン高さは１つのデータベースとして捉えてもよい。ブロックチェーンシステムは分散型システムであり、統一されたデータベースを持たないため、各ブロックチェーンノードが１つのデータベースを持つものと捉えてもよい。投票ノードのブロックチェーン高さがローカルブロックチェーン高さよりも高いということは、投票ノードのデータベースの更新度が記帳ノードのデータベースの更新度よりも優れていることを示しているので、ブロックグループヘッダを取得するためには、更新度の悪いデータベースから更新度の良いデータベースへのデータ同期化が必要である。

【0036】

上記ステップＳ４０６の別の実行形態として、一実施例では、前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するステップは、前記イベント原因が、前記ブロックチェーンシステムがブロックグループヘッダを生成していないことを示している場合、受信したブロックに投票するように投票ノードに指示し、受信していない正当なブロックの処理結果を目標値に設定して、投票ノードが前記受信していない正当なブロックに対して意見を持たないことを示し、前記投票ノードの投票結果を得るステップと、前記投票結果をラウンドロビン記帳ノードに送信し、前記生成されていない正当なブロックグループヘッダを生成するように前記ラウンドロビン記帳ノードに指示するステップと、を含む。本実施例では、記帳ノードがすべての投票ノードにそのブロックチェーン高さを要求する際には、前記記帳ノードのローカルブロックチェーン高さよりも高い投票ノードのブロックチェーン高さが見つからなかったので、ブロックチェーンシステムがブロックグループヘッダを生成していないと捉えてもよい。この場合、記帳ノードから受信したブロックに投票するようにすべての投票ノードに指示するとともに、受信していない正当なブロックの処理結果を目標値に設定して、前記投票ノードが前記受信していないブロックに対して意見を持たないことを示す。投票ノードは、すべての投票結果をラウンドロビン記帳ノードに送信して統計を行い、ラウンドロビン記帳ノードにブロックグループヘッダを生成させる。例えば、既存の記帳ノードＡ、記帳ノードＢ、記帳ノードＣ、投票ノードＸ、投票ノードＹ、投票ノードＺ、ラウンドロビン記帳ノードＭである。記帳ノードＡが投票ノードＸ、投票ノードＹ、投票ノードＺから所望のブロックグループヘッダに同期化していない場合、投票ノードＸ、投票ノードＹ、投票ノードＺは、既に受信した記帳ノードからのブロックに対して通常の投票を行う。記帳ノードＡからのブロックａと記帳ノードＢからのブロックｂを受信したと仮定すると、投票ノードＸ、投票ノードＹ、投票ノードＺはブロックａとブロックｂに対して通常の投票を行い、記帳ノードＣによって生成されたはずの受信していないブロックｃの投票結果を０（意見無し）に設定する。最後に、投票ノードＸ、投票ノードＹ、投票ノードＺはそれぞれ１枚の投票情報テーブルを生成してラウンドロビン記帳ノードＭに与え、ラウンドロビン記帳ノードＭは収集して統計し、ブロックグループヘッダを生成する。

【0037】

【0038】

【0039】

前記ターゲットノードがターゲットグループヘッダを正常に受信しているが、予め設定された数の正当なブロックを受信していない場合、前記ブロックチェーンシステムにおける他のノードに取得要求を送信する。前記取得要求は、前記他のノードから前記正当なブロックを取得するために使用される。前記他のノードは、前記ブロックチェーンシステムにおける前記ターゲットノード以外のノードであり、前記正当なブロックを保持している。例えば、記帳ノードＡは、ＰＰｏＶコンセンサス終了後に、ブロックグループヘッダを正常に受信しているが、ブロックｂ及びブロックｃが受信していないなど、ネットワーク故障により、十分な数のブロックを受信していない場合、記帳ノードＡは、ブロックチェーンネットワークにおける他のノードに、受信していないブロックｂ及びブロックｃを取得することをブロードキャストする。

【0040】

【0041】

【0042】

図６は、本発明の実施例に係るブロックチェーンノードのタイムアウト処理モジュールの構造図である。タイムアウト処理モジュールは、計時サブモジュールと、投票統計サブモジュールと、ビュー変換サブモジュールと、インセンティブサブモジュールとを含む。

【0043】

【0044】

【0045】

【0046】

インセンティブサブモジュールは、採点メカニズムと奨励メカニズムを実現する。具体的には、各投票ノードは、記帳ノードのリストを維持してスコアリングする。各記帳ノードに対するスコアは、その記帳ノードに対する信頼度を表し、投票ノードの投票の基準の１つとなる。１ラウンドの任期が終了すると、記帳ノードは、生成された正当なブロック及びブロックグループヘッダの数に応じてコンソーシアムから報酬を受け取る。

【0047】

タイムアウト後にＰＰｏＶコンセンサスアルゴリズムがどのように処理を行うか、すなわち、欠落したブロックグループヘッダ及びブロックをどのように取得するかをよりよく説明するために、以下では、図７を参照して説明する。図７は、本発明の実施例に係るブロックチェーンノードのタイムアウト処理のフローチャートである。例えば、記帳ノードのタイムアウト処理を例にして、一般的な非インセンティブシナリオに対して、具体的なタイムアウト処理は以下の２つのケースに分けられる。

【0048】

１つのケースは、記帳ノードが正当なブロックグループヘッダを受信しているが、十分な正当なブロックを受信していないことである。この場合、すでにブロックグループヘッダを生成していることはコンセンサスが完了していることを示しており、十分な正当なブロックが受信されていないのはネットワーク故障などが原因である可能性があるため、他のノードに不足している正当なブロックを要求すればよい。

【0049】

もう１つのケースは、ラウンドロビン記帳ノードが故障しているか、他の部分の記帳ノードが故障しているために、十分な数のブロックを生成できないことが原因で、記帳ノードが正当なブロックグループヘッダを受信していないことである。この場合、次のステップを実行する必要がある。

【0050】

ステップ１：記帳ノードは、すべての投票ノードにそのブロックチェーン高さを要求し、各投票ノードのオンライン状態をローカルで維持する。ローカルブロックチェーン高さよりも高いブロックチェーンが存在する投票ノードがあれば、ローカルブロックチェーン高さよりも高いブロックグループをそのノードに要求してデータを同期化し、次に、タイムアウト処理を終了する。それ以外の場合は、次のタイムアウト操作を続行する。

【0051】

ステップ２：すべての投票ノードがただちに投票操作を行い、すでに受信しているブロックの場合、通常通り投票を行い、まだ受信していないブロックの場合、結果を０（意見なし）に設定し、そのｈａｓｈ値を空に設定する。生成された投票は、次のｅｐｏｃｈのラウンドロビン記帳ノードに送信される必要がある。

【0052】

【0053】

【0054】

【0055】

一般的なインセンティブシナリオに対して、上記に加えて、タイムアウトのトリガは、記帳ノードの報酬の低下をともなう。詳細は次のとおりである。

【0056】

投票証明コンセンサスは採点メカニズムと奨励メカニズムを設計した。インセンティブシナリオでは、記帳ノードが選挙に参加して正当なブロックを生成する目的は、主に記帳手数料を得ることである。コンソーシアムチェーンシステムは、トークンの導入により記帳手数料の問題を解決することができ、トークンの金額単位及び換算は現実通貨の金額単位及び換算と１対１で対応する。コンソーシアムが成立した後、コンソーシアムファンド口座アドレスが設定され、現実に銀行にファンドを預け入れている現実口座に対応する。

【0057】

スコアが高い記帳ノードほど、より高い確率で投票を取得してリーダノードに当選する。正当なブロックグループのカプセル化に成功したリーダノードは、その数に応じた金額の奨励を取得し、より多くの人を記帳ノードの仲間入りに引きつけ、誠実に働く行為を奨励し、悪事を働く行為を罰し、システムをますます安全で信頼できるものとする。

【0058】

各投票ノードは１つの記帳ノードのリストを保持して、これについてスコアリングする。スコアリングのルールは以下のとおりである。

【0059】

ルール１：当該投票ノードでは、１つのブロックが検証を通過するたびに、対応する記帳ノードに加点を与え、検証を通過しなければ、記帳ノードに減点ないしクリアを行う。

【0060】

ルール２：１つのブロックグループヘッダが検証を通過するたびに、対応するリーダノードに加点を与え、検証を通過しなければ、リーダノードに減点ないしクリアを行う。

【0061】

ルール３：この記帳ノードがオンラインでないためにブロック生成を逃した場合、タイムアウトを誘発し、そのスコアはすべての投票ノードによって減点され、さらにはクリアされる。もしコンソーシアムプロトコルでオフライン行為に対するペナルティが比較的に重く、一律にクリアに設定されていれば、この記帳ノードが再びオンラインになる際に、点数を最初からやり直す必要があることを意味する。

【0062】

各投票ノードでの記帳ノードのスコアは異なる場合がある。各記帳ノードに対するスコアは、その記帳ノードに対する信頼度を表し、投票ノードの投票の基準の１つとなる。１ラウンドの任期が終了すると、記帳ノードは、生成された正当なブロック及びブロックグループヘッダの数に応じてコンソーシアムから報酬を受け取る。これにより、記帳ノードは、選挙に応募し、誠実に働き、長時間オンラインを維持する意欲を持つ。

【0063】

そのタイムアウト処理過程をよりよく理解するために、以下では、２つの実施例を参照して具体的に説明する。

【0064】

実施例１：並行投票証明コンセンサスに基づく非インセンティブ振込シナリオでは、ユーザＡがユーザＢの口座に自分の口座から資金の振り込みを要求すると仮定する。ユーザＡがＴｃｕｔまでに転送が成功したか否かを含むブロックグループを常に受信していない場合、タイムアウトがトリガされる。具体的な処理流れは次のとおりである。

【0065】

Ｓ１：ユーザＡは、まず、すべての投票ノードに最新のブロックチェーン高さを要求する。ローカルブロックチェーン高さよりもブロックチェーン高さが高い投票ノードが存在すれば、ローカルブロックチェーン高さよりも高いブロックグループをそのノードに要求してタイムアウト処理を終了する。それ以外の場合、ユーザＡは、すべての投票ノードとラウンドロビン記帳ノードに対してタイムアウト要求を開始する。

【0066】

【0067】

【0068】

実施例２：並行投票証明コンセンサスに基づく非インセンティブ標識登録シナリオでは、ユーザＸがネットワークに新たな標識を登録することを要求すると仮定する。ユーザＸがＴｃｕｔまでに標識が登録に成功したか否かを含むブロックグループを受信していない場合、タイムアウトがトリガされる。具体的な処理流れは以下のとおりである。

【0069】

Ｓ１：ユーザＸは、まず、すべての投票ノードに最新のブロックチェーン高さを要求する。ローカルブロックチェーン高さよりもブロックチェーン高さが高い投票ノードが存在すれば、ローカルブロックチェーン高さよりも高いブロックグループをそのノードに要求してタイムアウト処理を終了する。それ以外の場合、ユーザＸは、すべての投票ノード及びラウンドロビン記帳ノードに対してタイムアウト要求を開始する。

【0070】

【0071】

【0072】

上記のインセンティブシナリオ及び非インセンティブシナリオの場合、上記の記帳ノードが予め設定された条件を満たしていないことに対して、この処理ルールは、１つのコンセンサスラウンドにおいて、必ず１つの正当なブロックグループが生成されること、すなわち、記帳ノードが正当なブロックグループヘッダ及び十分な数のブロックを受信することを確保する。一方、従来のＰＰｏＶコンセンサスアルゴリズムでは、ブロックグループヘッダを生成するときに、記帳ノードが十分なブロックを生成していないため投票ノードが投票操作を行うことができないことにより、リーダノードは投票結果を受信できず、ブロックグループヘッダを生成することができない。上記のタイムアウト処理の過程でブロックグループヘッダを取得する方法は従来のＰＰｏＶコンセンサス過程に対する補充と完備であり、ブロックチェーンのロバスト性を向上させ、ブロックチェーンネットワークが異常な状況に遭遇した場合にも正常に運行し、ブロックを生成させることができる。

【0073】

以上の実施形態の説明から、上記の実施例に係る方法は、ソフトウェアに必要な汎用ハードウェアプラットフォームを加えて実現してもよく、もちろん、ハードウェアによって実現してもよいが、多くの場合、前者の方が好ましい実施形態である。このような知見に基づいて、本発明の技術案の本質的又は従来技術に貢献する部分は、１つの記憶媒体（例えば、ＲＯＭ／ＲＡＭ、磁気ディスク、光ディスク）に記憶されたソフトウェア製品の形態で具現化され、１つの端末機器（携帯電話、コンピュータ、サーバ、又はネットワーク機器などであってもよい）に本発明の様々な実施例の方法を実行させるためのいくつかの命令を含んでもよい。

【0074】

本実施例では、上記の実施例及び他の実施形態を実現するためのブロックグループヘッダの取得装置も提供されているが、既に説明したものについては、詳しく説明しない。以下で使用されるように、「モジュール」という用語は、所定の機能のソフトウェア及び／又はハードウェアの組み合わせを実装することができる。以下の実施例で説明される機器は、ソフトウェアで実装されることが好ましいが、ハードウェア、又はソフトウェアとハードウェアとの組み合わせの実装も可能であり、想定される。

【0075】

図８は、本発明の実施例に係るブロックグループヘッダの取得装置の構造ブロック図である。該取得装置は、第１決定モジュール８２と、第２決定モジュール８４と、第３決定モジュール８６と、を含む。
第１決定モジュール８２は、ブロックチェーンシステムにおけるターゲットノードが予め設定された条件を満たしているか否かを決定するように構成されている。前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示す。
第２決定モジュール８４は、前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定するように構成されている。前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムが前記ブロックグループヘッダを生成していないことの少なくとも１つを含む。
第３決定モジュール８６は、前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定するように構成されている。

【0076】

本発明によれば、ブロックチェーンシステムのターゲットノードが予め設定された条件を満たしているか否かを決定する。その予め設定された条件は、ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していない場合と、ターゲットノードがブロックグループヘッダを受信していない場合との２つの場合がある。２つの異なるポリシーはこの２つの場合に応じてそれぞれ設定される。ブロックグループヘッダを受信していない場合、ブロックグループヘッダを受信していないイベント原因を決定し、次に、前記イベント原因に基づいて、ターゲットノードが受信していないブロックグループヘッダをどのように取得するかを決定する。上記の技術案を採用して、並行投票証明ＰＰｏＶコンセンサスアルゴリズムではブロックグループヘッダを取得する過程において取得率が低いなどの問題を解決し、さらにブロックグループヘッダを取得する際に、異なるイベント原因に応じた取得方式を採用する。これによって、ブロックグループヘッダの取得率を高める。

【0077】

ＰＰｏＶコンセンサスアルゴリズムのコンセンサス終了条件は、前記第１決定モジュール８２において、ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していない条件１、及びターゲットノードがブロックグループヘッダを受信していない条件２を満たすことである。ブロックチェーンシステムにおけるターゲットノードは、予め設定された条件を満たしているか否かを判断する。満たしていない場合、タイムアウトをトリガし、前記ターゲットノードは、関連するタイムアウト操作を行う。前記ターゲットノードがブロックグループヘッダを受信していない場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定する。前記イベント原因は、前記ターゲットノードがブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む。その後、ブロックチェーンシステムは、前記イベント原因に基づいて、ターゲットノードが受信していないブロックグループヘッダをどのように取得するかを決定する。例えば、ブロックチェーンシステムのある記帳ノードＡはブロックグループヘッダを受信していないので、記帳ノードＡはタイムアウト操作をトリガして、すべての投票ノードにそのブロックチェーン高さを要求し、ローカルで各投票ノードのオンライン状態を維持する。ブロックチェーン高さが記帳ノードＡのローカルブロックチェーン高さよりも高い投票ノードが存在すれば、記帳ノードＡがブロックグループヘッダを正常に受信していないことを示している。もし見つからなければ、ブロックチェーンシステムはブロックグループヘッダを生成していないことを示している。その後、記帳ノードＡは、前記イベント原因に基づいて、取得方式を決定する。

【0078】

一方、前記第３決定モジュール８６は、さらに、前記イベント原因が、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないことを示している場合、前記ブロックチェーンシステムの投票ノードから、正常に受信していない前記ブロックグループヘッダを同期して取得するように構成されている。本実施例では、ターゲットノードがブロックグループヘッダを受信していない場合、ターゲットノードは、前記ブロックグループヘッダを取得するように投票ノードに要求する。投票ノードは、ブロックチェーンネットワークのコアコンセンサスポイントであるため、最新のブロックチェーン状態を有すると考えられる。システムがブロックグループヘッダを生成した場合、生成されたブロックグループヘッダがブロックチェーンネットワークにブロードキャストされる間、投票ノードは必ずそれを受信する。例えば、記帳ノードＡがブロックグループヘッダを受信していない場合、記帳ノードＡは、投票ノードＢにデータ同期化を行い、ブロックグループヘッダを取得し、ここで、投票ノードＢのブロックチェーン高さは記帳ノードＡよりも高い。

【0079】

いくつかの例では、ブロックチェーンシステムの投票ノードから正常に受信していない前記ブロックグループヘッダを同期して取得する過程において、ローカル記帳ノードのブロックチェーン高さよりも高い投票ノードからブロックグループを取得する必要があり、前記ブロックチェーン高さはブロック高さを示すために使用される。本実施例では、前記ブロックチェーン高さは１つのデータベースとして捉えてもよい。ブロックチェーンシステムは分散型システムであり、統一されたデータベースを持たないため、各ブロックチェーンノードが１つのデータベースを持つものと捉えてもよい。投票ノードのブロックチェーン高さがローカルブロックチェーン高さよりも高いということは、投票ノードのデータベースの更新度が記帳ノードのデータベースの更新度よりも優れていることを示しているので、ブロックグループヘッダを取得するためには、更新度の悪いデータベースから更新度の良いデータベースへのデータ同期化が必要である。

【0080】

前記第３決定モジュール８６は、さらに、前記イベント原因が、前記ブロックチェーンシステムがブロックグループヘッダを生成していないことを示している場合、受信したブロックに投票するように投票ノードに指示し、受信していない正当なブロックの処理結果を目標値に設定して、前記受信していない正当なブロックに対する投票ノードの意見がないことを示し、前記投票ノードの投票結果を得て、前記投票結果をラウンドロビン記帳ノードに送信し、前記生成されていない正当なブロックグループヘッダを生成するように前記ラウンドロビン記帳ノードに指示するように構成されている。本実施例では、記帳ノードがすべての投票ノードにそのブロックチェーン高さを要求する際には、前記記帳ノードのローカルブロックチェーン高さよりも高い投票ノードのブロックチェーン高さが見つからなかったので、ブロックチェーンシステムがブロックグループヘッダを生成していないと捉えてもよい。この場合、記帳ノードから受信したブロックに投票するようにすべての投票ノードに指示するとともに、受信していない正当なブロックの処理結果を目標値に設定して、前記投票ノードが前記受信していないブロックに対して意見を持たないことを示す。投票ノードは、すべての投票結果をラウンドロビン記帳ノードに送信して統計を行い、ラウンドロビン記帳ノードにブロックグループヘッダを生成させる。例えば、既存の記帳ノードＡ、記帳ノードＢ、記帳ノードＣ、投票ノードＸ、投票ノードＹ、投票ノードＺ、ラウンドロビン記帳ノードＭである。記帳ノードＡが投票ノードＸ、投票ノードＹ、投票ノードＺから所望のブロックグループヘッダに同期化していない場合、投票ノードＸ、投票ノードＹ、投票ノードＺは、既に受信した記帳ノードからのブロックに対して通常の投票を行う。記帳ノードＡからのブロックａと記帳ノードＢからのブロックｂを受信したと仮定すると、投票ノードＸ、投票ノードＹ、投票ノードＺはブロックａとブロックｂに対して通常の投票を行い、記帳ノードＣによって生成されたはずの受信していないブロックｃの投票結果を０（意見無し）に設定する。最後に、投票ノードＸ、投票ノードＹ、投票ノードＺはそれぞれ１枚の投票情報テーブルを生成してラウンドロビン記帳ノードＭに与え、ラウンドロビン記帳ノードＭは収集して統計し、ブロックグループヘッダを生成する。

【0081】

【0082】

【0083】

前記ターゲットノードがターゲットグループヘッダを正常に受信しているが、予め設定された数の正当なブロックを受信していない場合、前記ブロックチェーンシステムにおける他のノードに取得要求を送信する。前記取得要求は、前記他のノードから前記正当なブロックを取得するために使用される。前記他のノードは、前記ブロックチェーンシステムにおける前記ターゲットノード以外のノードであり、前記正当なブロックを保持している。例えば、記帳ノードＡは、ＰＰｏＶコンセンサス終了後に、ブロックグループヘッダを正常に受信しているが、ブロックｂ及びブロックｃが受信していないなど、ネットワーク故障により、十分な数のブロックを受信していない場合、記帳ノードＡは、ブロックチェーンネットワークにおける他のノードに、受信していないブロックｂ及びブロックｃを取得することをブロードキャストする。

【0084】

本発明の実施例は、実行されると上記方法の実施例のいずれかにおけるステップを実行するように構成されているコンピュータプログラムを記憶したコンピュータ読み取り可能な記憶媒体をさらに提供する。

【0085】

本実施例のいくつかの例では、上記の記憶媒体は、以下のステップを実行するためのコンピュータプログラムを記憶するように構成されてもよい。

【0086】

Ｓ１：ブロックチェーンシステムにおけるターゲットノードが、予め設定された条件を満たしているか否かを決定し、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示す。

【0087】

Ｓ２：前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定し、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む。

【0088】

Ｓ３：前記イベント原因に基づいて、前記ターゲットノードの、受信していない前記ブロックグループヘッダに対する取得方式を決定する。

【0089】

一実施例では、上記のコンピュータ読み取り可能な記憶媒体は、ＵＳＢメモリ、読出し専用メモリ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、略してＲＯＭ）、ランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、略してＲＡＭ）、リムーバブルハードディスク、磁気ディスク、又は光ディスクなど、コンピュータプログラムを記憶することができる様々な媒体を含んでもよいが、これらに限定されない。

【0090】

本実施例における具体例としては、上記実施例及び他の実施形態で説明した例を参照することができるので、本実施例についてはここでは説明しない。

【0091】

本発明の実施例は、コンピュータプログラムを記憶したメモリと、コンピュータプログラムを実行して上記方法の実施例のいずれかにおけるステップを実行するように構成されているプロセッサとを含む電子装置をさらに提供する。

【0092】

本実施例のいくつかの例では、上記プロセッサは、コンピュータプログラムによって以下のステップを実行するように構成されてもよい。

【0093】

Ｓ１：ブロックチェーンシステムにおけるターゲットノードが、予め設定された条件を満たしているか否かを決定し、前記予め設定された条件は、前記ターゲットノードがブロックグループヘッダを受信しているが、予め設定された数の正当なブロックを受信していないこと、及び前記ターゲットノードがブロックグループヘッダを受信していないことの少なくとも１つを示す。

【0094】

Ｓ２：前記ターゲットノードがブロックグループヘッダを受信していないと決定した場合、前記ターゲットノードがブロックグループヘッダを受信していないイベント原因を決定し、前記イベント原因は、前記ターゲットノードが前記ブロックグループヘッダを正常に受信していないこと、及び前記ブロックチェーンシステムがブロックグループヘッダを生成していないことの少なくとも１つを含む。

【0095】

Ｓ３：前記イベント原因に基づいて、前記ターゲットノードの受信していない前記ブロックグループヘッダに対する取得方式を決定する。

【0096】

一実施例では、上記電子装置は、伝送機器と、入出力機器と、をさらに含んでもよく、該伝送機器は上記プロセッサに接続され、該入出力機器は上記プロセッサに接続される。

【0097】

本実施例における具体例としては、上記実施例及び他の実施形態で説明した例を参照することができるので、本実施例についてはここでは説明しない。

【0098】

明らかに、当業者には、上記の本発明のモジュール又はステップは、汎用の計算装置を用いて実装することができ、それらは単一の計算装置に集積して実装してもよいし、複数の計算装置からなるネットワークに分散して実装してもよく、計算装置によって実行可能なプログラムコードを用いて実装することができ、したがって、それらは、計算装置によって実行されるように記憶装置に記憶することができ、場合によっては、示された又は説明されたステップは、本明細書とは異なる順序で実行してもよく、又は、これらは個々の集積回路モジュールとして実装することができ、又は、それらのうちの複数のモジュール又はステップは、単一の集積回路モジュールとして実装することができる。したがって、本発明は、いかなる特定のハードウェア及びソフトウェアの組み合わせにも限定されない。

【0099】

上記は、本発明のいくつかの実施例に過ぎず、本発明を限定するものではなく、当業者にとって本発明は様々な変更及び変更が可能である。本発明の原則内で行われる補正、均等置換、改良などはすべて本発明の保護範囲内に含まれるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【国際調査報告】