JP6940615B2 - データ処理方法およびデバイス - Google Patents

Description

本願は、コンピュータ技術の分野に関し、詳細には、データ処理方法およびデバイスに関する。

ブロックチェーンは、分散型データ・ストレージ、２地点間伝送、コンセンサス・メカニズム、暗号アルゴリズムなどのコンピュータ技術の新たな応用であり、全てのブロックチェーン・ノードが同じ状態（データベースの状態も含む）であることを必要とする。そのため、ブロックチェーン・ノードで新たなトランザクションが生成されると（すなわち新たなデータが生成されると）、その新たなデータを全てのブロックチェーン・ノードと同期させる必要があり、全てのブロックチェーン・ノードがそのデータを検証する必要がある。

現在の技術では、データに対してブロックチェーン・ノードが使用する検証方法は、通常は、バケット・ツリーに基づくチェックサム（例えばハッシュ値）を通して決定される。１つの例では、ファブリック（既に実施されているブロックチェーンの応用例）のブロックチェーン・ノードのデータは、マークル・ツリー構造で記憶され、このマークル・ツリーは、１つまたは複数のリーフ・ノード（すなわちバケット）を含む。これらのブロックチェーン・ノードが上記のデータのチェックサム（例えばハッシュ値）を得るために、通常は１つの計算デバイス（例えば端末デバイスまたはサーバ）が使用される。例えば、計算デバイスが各リーフ・ノードをトラバースし、そのリーフ・ノードのデータをランク付けし、文字列にスプライスし、その文字列のチェックサムを、対応するリーフ・ノードのデータのチェックサムとして計算する。次いで、計算デバイスは、各リーフ・ノードのデータのチェックサムに基づいて、マークル・ツリーのルート・チェックサム（例えばルート・ハッシュ値）、すなわちそのブロックチェーン・ノードのデータのチェックサムを計算する。上記のデータは、このチェックサムに基づいて検証することができる。

しかし、ブロックチェーン・ノードのデータのルート・チェックサムを計算するのに計算デバイスが１つしか使用されず、各計算もリーフ・ノードのデータを文字列にスプライスすることによって完了するので、１つまたは複数のリーフ・ノードにおける累積データ量が非常に大きい（例えば１千万個のデータなど）ときには、その１つの計算デバイスが上述の計算プロセスを実行するのに長い時間がかかり、これにより計算効率が低くなり、さらには、ブロック生成する時間が遅れ、ブロックチェーンの正常な動作の妨げになることもある。

本願の実施形態の目的は、計算プロセスにかかる時間を短縮し、計算効率を向上させ、ブロックの正常な生成およびブロックチェーンの正常な動作を保証するように、データ処理方法およびデバイスを提供することである。

上述の技術的問題を解決するために、本願の実施形態は、以下のように実施される。
本願の実施形態は、データ処理方法であって、
ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが、分散したリーフ・ノードのデータのチェックサムをそれぞれ計算するステップと、
サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムを得るステップと、を含む、データ処理方法を提供する。

任意選択で、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムを得るステップは、
サーバ・クラスタ内のサーバから送信されたブロックチェーン・ノードのデータのルート・チェックサムを受信するステップを含む。

任意選択で、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムを得るステップは、
リーフ・ノードのチェックサムに従って、リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定するステップと、
マークル・ツリーのルート・チェックサムを、ブロックチェーン・ノードのデータのルート・チェックサムとして指定するステップと、を含む。

任意選択で、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させるステップは、
ブロックチェーン・ノードに事前記憶されているリーフ・ノードの個数に従って、予め設定された個数のリーフ・ノードのデータをサーバ・クラスタ内のサーバにそれぞれ送信するステップを含む。

任意選択で、チェックサムは、ハッシュ値である。

本願の実施形態は、さらに、データ処理方法であって、
ブロックチェーン・ノードによって分散されたリーフ・ノードのデータを受信するステップと、
分散したリーフ・ノードのデータのチェックサムを計算して、ブロックチェーン・ノードのデータのルート・チェックサムを得るステップと、を含む、データ処理方法を提供する。

任意選択で、ブロックチェーン・ノードによって分散されたリーフ・ノードのデータを受信するステップの後で、この方法は、
リーフ・ノードのデータ量に従って、リーフ・ノードのデータを予め設定されたサブリーフ・ノードに分散させるステップと、
各サブリーフ・ノードのデータのチェックサムを計算するステップと、をさらに含み、
分散したリーフ・ノードのデータのチェックサムを計算するステップは、
各サブリーフ・ノードのデータのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するステップを含む。

任意選択で、リーフ・ノードのデータ量に従って、リーフ・ノードのデータを予め設定されたサブリーフ・ノードに分散させるステップは、
リーフ・ノードのデータをソートするステップと、ソートしたデータから予め設定された個数のデータを順番に選択して、サブリーフ・ノードに配置するステップと、サブリーフ・ノードについて、対応するサブノード識別子を設定するステップとを含み、
各サブリーフ・ノードのデータのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するステップは、
サブリーフ・ノードのサブノード識別子、およびサブリーフ・ノードのそれぞれのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するステップを含む。

任意選択で、分散したリーフ・ノードのデータのチェックサムを計算して、ブロックチェーン・ノードのデータのルート・チェックサムを得るステップは、
分散したリーフ・ノードのデータのチェックサムを計算し、分散したリーフ・ノードのデータのチェックサムをブロックチェーン・ノードに送信して、ブロックチェーン・ノードが、リーフ・ノードのデータのチェックサムに従ってブロックチェーン・ノードのデータのルート・チェックサムを計算するステップ、または
分散したリーフ・ノードのデータのチェックサムを計算し、分散したリーフ・ノードのデータのチェックサムに基づいてブロックチェーン・ノードのデータのルート・チェックサムを得、ルート・チェックサムをブロックチェーン・ノードに送信するステップを含む。

本願の実施形態は、データ処理デバイスであって、
ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが、分散したリーフ・ノードのデータのチェックサムをそれぞれ計算するように構成されたデータ分散モジュールと、
サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成されたルート・チェックサム取得モジュールと、を備える、データ処理デバイスを提供する。

任意選択で、ルート・チェックサム取得モジュールは、サーバ・クラスタ内のサーバから送信されたブロックチェーン・ノードのデータのルート・チェックサムを受信するように構成される。

任意選択で、ルート・チェックサム取得モジュールは、リーフ・ノードのチェックサムに従って、リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定し、マークル・ツリーのルート・チェックサムを、ブロックチェーン・ノードのデータのルート・チェックサムとして指定するように構成される。

任意選択で、データ分散モジュールは、ブロックチェーン・ノードに事前記憶されているリーフ・ノードの個数に従って、予め設定された個数のリーフ・ノードのデータをサーバ・クラスタ内のサーバにそれぞれ送信するように構成される。

任意選択で、チェックサムは、ハッシュ値である。

本願の実施形態は、さらに、データ処理デバイスであって、
ブロックチェーン・ノードによって分散されたリーフ・ノードのデータを受信するように構成されたデータ受信モジュールと、
分散したリーフ・ノードのデータのチェックサムを計算して、ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成されたチェックサム取得モジュールと、を備える、データ処理デバイスを提供する。

任意選択で、このデバイスは、
リーフ・ノードのデータ量に従って、リーフ・ノードのデータを予め設定されたサブリーフ・ノードに分散させるように構成されたデータ分散モジュールと、
各サブリーフ・ノードのデータのチェックサムを計算するように構成された計算モジュールと、をさらに備え、
チェックサム取得モジュールは、各サブリーフ・ノードのデータのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するように構成される。

任意選択で、データ分散モジュールは、リーフ・ノードのデータをソートし、ソートしたデータから予め設定された個数のデータを順番に選択して、サブリーフ・ノードに配置し、サブリーフ・ノードについて、対応するサブノード識別子を設定するように構成され、チェックサム取得モジュールは、サブリーフ・ノードのサブノード識別子、およびサブリーフ・ノードのそれぞれのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するように構成される。

任意選択で、チェックサム取得モジュールは、分散したリーフ・ノードのデータのチェックサムを計算し、分散したリーフ・ノードのデータのチェックサムをブロックチェーン・ノードに送信して、ブロックチェーン・ノードが、リーフ・ノードのデータのチェックサムに従ってブロックチェーン・ノードのデータのルート・チェックサムを計算するように構成される、または分散したリーフ・ノードのデータのチェックサムを計算し、分散したリーフ・ノードのデータのチェックサムに基づいてブロックチェーン・ノードのデータのルート・チェックサムを得、ルート・チェックサムをブロックチェーン・ノードに送信するように構成される。

本願の実施形態によって提供される上記の技術的解決策から、本願の実施形態では、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが、分散したリーフ・ノードのデータのチェックサムをそれぞれ計算するようにし、次いで、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムがさらに得られることが分かる。このように、リーフ・ノードのデータがサーバ・クラスタに分散され、次いで分散したリーフ・ノードのデータのチェックサムがサーバ・クラスタ内の各サーバによって計算されるので、データをサーバ・クラスタに分散させて、リーフ・ノードのデータのチェックサムの並列計算を行うことができ、それにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証することができる。

本願の実施形態における技術的解決策、または現況技術をより明確に説明するために、以下、実施形態または現況技術の説明で使用される添付の図面について簡単に説明する。以下に説明する添付の図面は、単に本願のいくつかの実施形態に過ぎないことは明らかである。これらの添付の図面に基づいて、当業者なら、創造的努力なしに他の関連する図面を得ることができる。

本願によるデータ処理方法である。 本願によるデータ処理論理を示す概略図である。 本願のいくつかの実施形態による別のデータ処理方法である。 本願のいくつかの実施形態によるさらに別のデータ処理方法である。 本願によるデータ処理システムを示す概略構造図である。 本願のいくつかの実施形態によるさらに別のデータ処理方法である。 本願のいくつかの実施形態によるさらに別のデータ処理方法である。 本願による別のデータ処理システムを示す概略構造図である。 本願のいくつかの実施形態によるデータ処理デバイスである。 本願のいくつかの実施形態による別のデータ処理デバイスである。

本願の実施形態は、データ処理方法およびデバイスを提供するものである。

当業者が本願の技術的解決策をより十分に理解することができるように、以下、本願の実施形態における技術的解決策について、本願の実施形態における添付の図面を参照して明確かつ完全に説明する。記載する実施形態は、本願の実施形態の全てではなく、一部に過ぎないことは明らかである。本願のこれらの実施形態に基づいて創造的努力なしに当業者が得ることができるその他の全ての実施形態は、本願の範囲に含まれるものとする。

第１の実施形態
図１に示すように、本願の実施形態は、データ処理方法を提供する。この方法を実行するエンティティは、ブロックチェーン・ノードである。この方法は、以下のステップを含むことがある。

ステップＳ１０１で、サーバ・クラスタ内の複数のサーバに、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータを分散させて、サーバ・クラスタ内のそれらのサーバが、分散したリーフ・ノードのデータのチェックサムをそれぞれ計算する。

ここで、リーフ・ノードは、サブノードを有していないこともある。ブロックチェーン・ノードは、通常は、１つまたは複数のリーフ・ノード（すなわちバケット）を含み、各リーフ・ノードは、ある量のデータ（例えばトランザクション・データであることもある）を記憶している。リーフ・ノードに記憶された各データのデータ量について、対応する数値を設定することができる。例えば、各データのデータ量は、１００ＫＢから５ＭＢの範囲内であり、一例では１ＭＢである。サーバ・クラスタは、複数の同じまたは異なるサーバによって構成されるグループとすることができ、１つまたは複数のトランザクションに対応するサービスを提供することができることがある。チェックサムは、ファイルまたはデータを検査するために使用される文字列（例えば数値またはコード）であることがある。例示的な応用例では、チェックサムは、データ要約などに基づく検査アルゴリズムを使用した計算から得られる数値であることもある。データ要約に基づく検査アルゴリズムは、巡回冗長検査アルゴリズム、メッセージ・ダイジェスト・アルゴリズム、セキュア・ハッシュ・アルゴリズムなどを含む可能性がある。

実装態様では、ブロックチェーンは、非集中型の分散型データベースであることがあり、これは、分散型レジャーとも呼ばれる。ブロックチェーン技術に基づくと、多数の情報記録メモリ（例えば端末デバイスまたはサーバ）によって構成される分散型ネットワークが必要となる。新たなトランザクションそれぞれの伝搬は、分散型ネットワークを使用することができ、ピア・ツー・ピア（Ｐ２Ｐ）ネットワーク・レイヤ・プロトコルによれば、トランザクションに関連する情報が、個々のブロックチェーン・ノードによってネットワークを介して他の全てのブロックチェーン・ノードに直接送信されて、その分散型ネットワーク内の全てのブロックチェーン・ノードに記憶されるデータが一貫していることが保証されるようにする。あるブロックチェーン・ノードが新たなトランザクションを記録すると、その記録された新たなトランザクションのデータを他のブロックチェーン・ノードと同期させる必要があるが、その一方で、他のブロックチェーン・ノードは、そのデータを検証する必要もある。例示的な検証プロセスは、以下のようなものであることもある。
ブロックチェーン・ノードは、１つまたは複数のリーフ・ノードを含み、ブロックチェーン・ノード内のデータは、それらのリーフ・ノードに分散される。ここで、リーフ・ノード内の全てのデータは、受信タイムスタンプを含み、トランザクションの順序は、タイムスタンプに従って決定することができる。検証中には、ブロックチェーン・ノードは、最初にそのブロックチェーン・ノード内に事前記憶されているリーフ・ノードを得ることができる。どんなリーフ・ノードがブロックチェーン・ノードに記憶されているかを迅速に決定し、またそれらのリーフ・ノードの個数を迅速に決定することができるように、５またはＡ８など、対応するノード識別子（例えばノードＩＤ（識別情報））を、各リーフ・ノードについて、そのリーフ・ノードが生成されたときに設定することができる。リーフ・ノードを得るときには、予め記録されているノード識別子によって対応するリーフ・ノードを検索し、各リーフ・ノードに記憶されているデータを得ることができる。

記憶されるデータの量は、期間の相違および／または領域の相違などの要因の影響によって異なる可能性があるので、結果として、１つまたは複数のリーフ・ノードに蓄積されるデータの量が比較的大きくなる一方で、他のいくつかのリーフ・ノードのデータの量は比較的小さくなることがある。このように、ブロックチェーン・ノードのリーフ・ノードに記憶されるデータ量に不均衡があることもある。ブロックの生成に影響を及ぼさないように、またリーフ・ノードのデータのチェックサムの計算に要する時間を短縮するために、リーフ・ノード内のデータを、サーバ・クラスタ内の複数のプロセッサに分散させて処理し、計算負荷をサーバ・クラスタ全体で拡散させることによって、計算効率を改善することもできる。

ブロックチェーン・ノードは、全てのリーフ・ノードのデータを得た後で、リーフ・ノードを単位として、リーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させることができる。例えば、サーバ・クラスタ内のサーバの個数がリーフ・ノードの個数と等しいこともあり、その場合には、ブロックチェーン・ノードは、１つのリーフ・ノードのデータをサーバ・クラスタ内の各サーバに送信して、サーバ・クラスタ内の各サーバに１つのリーフ・ノードのデータのみを含めることができる。上述の分散方法に加えて、複数の分散方式を使用することもできる。例えば、リーフ・ノードおよびリーフ・ノードのデータを、ランダム分散方式でサーバ・クラスタ内のサーバに送信する。このようにして、異なるサーバが同数のリーフ・ノードを受信することも、異なる個数のリーフ・ノードを受信することもある。別の例として、リーフ・ノードのデータを、リーフ・ノードのデータの量に応じて分散させることもできる。一例では、ブロックチェーン・ノードが、各リーフ・ノードのデータの量をカウントし、次いでリーフ・ノードのデータをサーバ・クラスタ内のサーバに均一に分散させることもある。例えば、データ量がそれぞれ５０ＭＢ、２０ＭＢ、３０ＭＢ、４０ＭＢ、１０ＭＢ、および１０ＭＢである６個のリーフ・ノードがある場合には、データ量が５０ＭＢであるリーフ・ノードのデータを、サーバ・クラスタ内の第１のサーバに送信し、データ量が２０ＭＢであるリーフ・ノードおよびデータ量が３０ＭＢであるリーフ・ノードのデータを、サーバ・クラスタ内の第２のサーバに送信し、データ量が４０ＭＢであるリーフ・ノード、データ量が１０ＭＢであるリーフ・ノード、およびデータ量が１０ＭＢであるリーフ・ノードのデータを、サーバ・クラスタ内の第３のサーバに送信することもある。

サーバは、リーフ・ノードの分散データを受信した後で、各リーフ・ノードの受信データのチェックサムを計算することができる。例えば、サーバは、メッセージ・ダイジェスト・アルゴリズム（例えばＭＤ５アルゴリズム）を使用してリーフ・ノードの受信データのＭＤ５値を計算する。１つのサーバが２つのリーフ・ノードのデータ、すなわちリーフ・ノード１のデータおよびリーフ・ノード２のデータを受信する場合には、サーバは、リーフ・ノード１のデータのＭＤ５値、およびリーフ・ノード２のデータのＭＤ５値を計算することによって、各リーフ・ノードの受信データのチェックサムを得ることができる。

ステップＳ１０２で、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムをさらに得る。

実装態様では、サーバ・クラスタ内のサーバがリーフ・ノードのデータのチェックサムを計算した後で、各サーバは、そのサーバが計算したリーフ・ノードのデータのチェックサムを、ブロックチェーン・ノードに送信することができる。ブロックチェーン・ノードがそのブロックチェーン・ノードに記憶されている全てのリーフ・ノードのデータのチェックサムを受信した後で、ブロックチェーン・ノードは、その全てのリーフ・ノードのデータのチェックサムに基づいて、ブロックチェーン・ノード内のデータのルート・チェックサム（すなわち状態）を計算することができる。ここで、ブロックチェーン・ノードがそのブロックチェーン・ノード内のデータのルート・チェックサムを計算するときには、リーフ・ノードと、ルート・チェックサムに対応するルート・ノードとの間に、複数の中間ノードを設けることができる。図２に示すように、Ａ、Ｂ、Ｃ、およびＤがリーフ・ノードであり、Ａ１、Ａ２、Ａ３、…、Ａｐ、Ｂ１、Ｂ２、Ｂ３、…、Ｂｑ、Ｃ１、Ｃ２、Ｃ３、…、Ｃｒ、およびＤ１、Ｄ２、Ｄ３、…、Ｄｋが、それぞれデータを表す。一例としてチェックサムがハッシュ値であるとすると、リーフ・ノードＡのハッシュ値は、ｈａｓｈ（Ａ１Ａ２Ａ３…Ａｐ）であり、リーフ・ノードＢのハッシュ値は、ｈａｓｈ（Ｂ１Ｂ２Ｂ３…Ｂｑ）であり、リーフ・ノードＣのハッシュ値は、ｈａｓｈ（Ｃ１Ｃ２Ｃ３…Ｃｒ）であり、リーフ・ノードＤのハッシュ値は、ｈａｓｈ（Ｄ１Ｄ２Ｄ３…Ｄｋ）である。ＭおよびＮは、中間ノードであり、したがって、リーフ・ノードＭのハッシュ値は、ｈａｓｈ（ＡＢ）であり、リーフ・ノードＮのハッシュ値は、ｈａｓｈ（ＣＤ）である。この場合、ルート・ノードのルート・チェックサムは、ｈａｓｈ（ＭＮ）である。得られたブロックチェーン・ノード内のデータのルート・チェックサムを、新たなトランザクション・データを送信するブロックチェーン・ノードによって計算された上述のルート・チェックサムと比較することにより、ブロックチェーン・ノードは、その新たなトランザクション・データが有効であるかどうかを検証することができる。新たなトランザクション・データが有効である場合には、ブロックチェーン・ノードは、そのトランザクションに関連するデータを記録することができ、新たなトランザクション・データが有効でない場合には、ブロックチェーン・ノードは、そのトランザクションに関連するデータを記録することを拒否することができる。

なお、上述のルート・チェックサム計算プロセスは、サーバ・クラスタによって完了されることもあることに留意されたい。一例では、管理サーバまたは管理サーバ・クラスタを、サーバ・クラスタに設けることができ、この管理サーバまたは管理サーバ・クラスタが、サーバ・クラスタ内の他のサーバを調節および制御することができる。サーバ・クラスタ内の他のサーバは、リーフ・ノードのデータのチェックサムを計算した後で、リーフ・ノードのデータのチェックサムを管理サーバまたは管理サーバ・クラスタにそれぞれ送信すればよい。管理サーバまたは管理サーバ・クラスタは、上述の計算方法を使用して、ブロックチェーン・ノード内のデータのルート・チェックサムを計算することができる。管理サーバまたは管理サーバ・クラスタは、得られたブロックチェーン・ノード内のデータのルート・チェックサムをブロックチェーン・ノードに送信することができ、ブロックチェーン・ノードは、このルート・チェックサムを受信する。次いで、ブロックチェーン・ノードは、このルート・チェックサムを介して検証を実行することができる。詳細については上記の関連する内容を参照すればよいので、ここでは詳細には説明しない。

このように、ブロックチェーン・ノード内のリーフ・ノードのデータのチェックサムを、サーバ・クラスタ内の複数のサーバによる並列計算によって得て、ブロックチェーン・ノード内のデータのルート・チェックサムの計算を、１つのマシンによる処理から切り離すことにより、データ・チェックサム計算の効率を改善する。

本願の実施形態は、データ処理方法であって、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが分散したリーフ・ノードのデータのチェックサムをそれぞれ計算することと、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノード内のデータのルート・チェックサムをさらに得ることとを含む、データ処理方法を提供する。このように、リーフ・ノードのデータがサーバ・クラスタに分散され、次いで分散したリーフ・ノードのデータのチェックサムがサーバ・クラスタ内の各サーバによって計算されるので、データをサーバ・クラスタに分散させて、リーフ・ノードのデータのチェックサムの並列計算を行うことができ、それにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証することができる。

図３に示すように、本願の実施形態は、データ処理方法を提供する。この方法を実行するエンティティは、サーバ・クラスタであることもあり、このサーバ・クラスタが、複数のサーバを含むこともあり、各サーバが、データ・チェックサムを計算することもある。この方法は、以下のステップを含む可能性がある。

ステップＳ３０１で、ブロックチェーン・ノードによって分散したリーフ・ノードのデータを受信する。

実装態様では、ブロックチェーン・ノード内のデータを検証する必要があるときには、ブロックチェーン・ノードは、そのブロックチェーン・ノードに記憶されているリーフ・ノードのデータを得、リーフ・ノードを単位として、リーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させることができる。詳細な分散方式および分散プロセスについては、上述したステップＳ１０１の関連する内容を参照すればよいので、ここでは詳細には説明しない。サーバ・クラスタ内のサーバは、ブロックチェーン・ノードによって分散されたリーフ・ノードのデータをそれぞれ受信することができるが、詳細については上述したステップＳ１０１の関連する内容を参照すればよいので、ここでは詳細には説明しない。

ステップＳ３０２で、分散したリーフ・ノードのデータのチェックサムを計算して、ブロックチェーン・ノード内のデータのルート・チェックサムを得る。

実装態様では、サーバ・クラスタ内のサーバは、受信した各リーフ・ノードのデータのチェックサムを計算することができる。計算が完了した後で、サーバ・クラスタ内のサーバは、得られたリーフ・ノードのデータのチェックサムをブロックチェーン・ノードにそれぞれ送信することができる。ブロックチェーン・ノードは、サーバから返送されたリーフ・ノードのデータのチェックサムに基づいて、そのブロックチェーン・ノードのデータのルート・チェックサムをさらに計算することができる。詳細については上述したステップＳ１０２の関連する内容を参照すればよいので、ここでは詳細には説明しない。

本願のいくつかの他の実施形態では、ブロックチェーン・ノードのデータのルート・チェックサムは、サーバ・クラスタが計算することもある。上述のように、サーバ・クラスタに管理サーバまたは管理サーバ・クラスタを設けて、各リーフ・ノードのデータの計算したチェックサムについての計算を集約的に実行して、ブロックチェーン・ノードのデータのルート・チェックサムを得ることもできる。詳細については上述したステップＳ１０２の関連する内容を参照すればよいので、ここでは詳細には説明しない。

本願の実施形態は、データ処理方法であって、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが分散したリーフ・ノードのデータのチェックサムをそれぞれ計算することと、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノード内のデータのルート・チェックサムをさらに得ることとを含む、データ処理方法を提供する。このように、リーフ・ノードのデータがサーバ・クラスタに分散され、次いで分散したリーフ・ノードのデータのチェックサムがサーバ・クラスタ内の各サーバによって計算されるので、データをサーバ・クラスタに分散させて、リーフ・ノードのデータのチェックサムの並列計算を行うことができ、それにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証することができる。

第２の実施形態
図４に示すように、本願の実施形態は、データ処理方法を提供する。このデータ処理方法は、ブロックチェーン・ノードおよびサーバ・クラスタによって協働で実行されることがある。チェックサムがハッシュ値である場合を例にとって、本願の実施形態について詳細に説明する。本願の実施形態の関連する内容を参照して他の形態のチェックサムを実行することもできるが、ここでは詳細には説明しない。この方法は、以下のステップを含む可能性がある。

ステップＳ４０１で、事前記憶されているリーフ・ノードの個数に従って、ブロックチェーン・ノードは、予め設定された個数のリーフ・ノードのデータをサーバ・クラスタ内のサーバのそれぞれに送信する。

ここで、上記の予め設定された数は、５、１０など、実際の状況に応じて設定することができるが、本願の実施形態では詳細には説明しない。

実装態様では、トランザクション・データを検証するときには、ブロックチェーン・ノードのデータについてマークル・ツリーの設計機構を利用して、検証効率を改善し、リソース消費を低減することが多い。本願の実施形態におけるブロックチェーン・データの既存の設計機構を変更することなく、ブロックチェーン・ノードのデータのチェックサムの計算効率を大幅に改善するために、本願の実施形態におけるブロックチェーン・ノードのデータは、依然としてマークル・ツリーの設計機構を使用することができる。マークル・ツリーは、複数のリーフ・ノード（すなわちバケット）を含むことがあり、マークル・ツリー内の全てのリーフ・ノードのノード識別子を、ブロックチェーン・ノードに記録することができる。トランザクション・データを検証する必要があるときには、マークル・ツリー内の全てのリーフ・ノードのノード識別子を得ることができる。

図５に示すように、ブロックチェーン・ノードは、全てのリーフ・ノードのノード識別子に基づいて全てのリーフ・ノードのデータをそれぞれ得ることができ、また、ブロックチェーン・ノードに記憶されたリーフ・ノードの個数、およびサーバ・クラスタ内のサーバの個数を得ることもできる。サーバの個数、およびリーフ・ノードの個数に応じて、ブロックチェーン・ノードは、各サーバに分散させるリーフ・ノードの個数を決定することができる。例えば、全部で１０個のリーフ・ノードがあり、サーバ・クラスタは、総数で１０個のサーバを有する。この場合には、１つのリーフ・ノードのデータを各サーバに送信することもできるし、あるいは２つまたは５つのリーフ・ノードのグループのデータをサーバ・クラスタ内の１つのサーバに送信することもできる。

ブロックチェーン・ノードがリーフ・ノードのデータをサーバ・クラスタに分散させるプロセスでは、ブロックチェーン・ノードは、リーフ・ノードのノード識別子をサーバ・クラスタ内のサーバに分散させることもできる。分散したノード識別子に従って、サーバは、ノード識別子を含むデータ取得命令をブロックチェーン・ノードに送信することができる。ブロックチェーン・ノードは、データ取得命令を受信すると、データ取得命令中のノード識別子を抽出し、そのノード識別子によって対応するリーフ・ノードのデータを検索し、データを対応するサーバに送信することができる。このようにして、サーバ・クラスタは、１つの対応するリーフ・ノードのデータから、複数の対応するリーフ・ノードのデータを引き出すことができる。

なお、例示的な応用例では、リーフ・ノードのデータは、リーフ・ノードのデータ量に応じてサーバ・クラスタ内のサーバに分散させることもできるし、あるいはランダムにサーバ・クラスタ内のサーバに分散させることもできることに留意されたい。詳細については第１の実施形態のステップＳ１０１の関連する内容を参照すればよいので、ここでは詳細には説明しない。

ステップＳ４０２で、サーバ・クラスタは、分散したリーフ・ノードのデータのチェックサムを計算する。

ステップＳ４０３で、サーバ・クラスタは、分散したリーフ・ノードのデータのチェックサムをブロックチェーン・ノードに送信する。

上記のステップＳ４０２およびＳ４０３の詳細なプロセスについては第１の実施形態の関連する内容を参照すればよいので、ここでは詳細には説明しない。

ステップＳ４０４で、ブロックチェーン・ノードは、リーフ・ノードの上記のチェックサムに従って、リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定する。

実装態様では、ブロックチェーン・ノードは、サーバ・クラスタ内のサーバから送信されたリーフ・ノードのチェックサムを受信した後で、それらのリーフ・ノードを通して対応するマークル・ツリーを構築することができる。マークル・ツリー上のリーフ・ノードのハッシュ値は既に決定されているが、マークル・ツリーのルート・ノードのハッシュ値（すなわちマークル・ツリーのルート・チェックサム）はまだ得られていないので、これらのリーフ・ノードに対応するマークル・ツリーのハッシュ値をリーフ・ノードのハッシュ値から上向きに計算することによって、これらのリーフ・ノードに対応するマークル・ツリーのルート・チェックサムを得ることができる。

ステップＳ４０５で、ブロックチェーン・ノードは、マークル・ツリーのルート・チェックサムを、ブロックチェーン・ノードのデータのルート・チェックサムとして指定する。

例示的な応用例では、ルート・チェックサムは、サーバ・クラスタによって計算することもでき、この処理は、分散したリーフ・ノードのデータのチェックサムを計算することと、分散したリーフ・ノードのデータのチェックサムに基づいて、ブロックチェーン・ノードのデータのルート・チェックサムを得ることと、このルート・チェックサムをブロックチェーン・ノードに送信することとを含む可能性がある。詳細なプロセスについては第１の実施形態の関連する内容を参照すればよいので、ここでは詳細には説明しない。

本願の実施形態は、データ処理方法であって、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが分散したリーフ・ノードのデータのチェックサムをそれぞれ計算することと、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノード内のデータのルート・チェックサムをさらに得ることとを含む、データ処理方法を提供する。このように、リーフ・ノードのデータがサーバ・クラスタに分散され、次いで分散したリーフ・ノードのデータのチェックサムがサーバ・クラスタ内の各サーバによって計算されるので、データをサーバ・クラスタに分散させて、リーフ・ノードのデータのチェックサムの並列計算を行うことができ、それにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証することができる。

第３の実施形態
図６に示すように、本願の実施形態は、データ処理方法を提供する。このデータ処理方法は、ブロックチェーン・ノードおよびサーバ・クラスタによって協働で実行されることがある。チェックサムがハッシュ値である場合を例にとって、本願の実施形態について詳細に説明する。本願の実施形態の関連する内容を参照して他の形態のチェックサムを実行することもできるが、ここでは詳細には説明しない。この方法は、以下のステップを含む可能性がある。

ステップＳ６０１で、ブロックチェーン・ノードは、事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散する。

ステップＳ６０１の詳細なプロセスについては、第１の実施形態および第２の実施形態の関連する内容を参照すればよいので、ここでは詳細には説明しない。

ステップＳ６０２で、サーバ・クラスタは、リーフ・ノードのデータ量に従って、リーフ・ノードのデータを予め設定されたサブリーフ・ノードに分散する。

ここで、サブリーフ・ノードとリーフ・ノードとの間には、帰属関係、従属関係、親関係、または子関係などの関連関係はない。サブリーフ・ノードは、１つまたは複数個のデータを含むデータ・パケットであることがあり、リーフ・ノード（バケット）は、データを記憶するためのマークル・ツリー内のコンテナであることがある。サブリーフ・ノードの個数は、リーフ・ノードの個数より大きいことがある。例えば、リーフ・ノードの個数が５である場合に、サブリーフ・ノードの個数が２０であることもある。

実装態様では、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのうちの１つまたは複数のリーフ・ノードが、大きなデータ量を有することがある（例えば百万個のデータを含むなど）。このように、リーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、そのリーフ・ノードのハッシュ値を計算するときには、サーバは、リーフ・ノード内の大量のデータをスプライスして、スプライスした文字列を得る必要があり、その後、スプライスした文字列のハッシュ値を計算する。このプロセスは、依然として長い時間がかかり、サーバによるリソース消費も依然として大きい。このことに鑑みて、複数のサブリーフ・ノードが予め設定することもでき、あるいは、例えば１ＧＢまたは５００ＭＢなど、各サブリーフ・ノードが収容することができる最大データ量を、実際の必要に応じて各サブリーフ・ノードに設定することもできる。リーフ・ノードのデータは、ランダム分散方式または均一分散方式で、予め設定された複数のサブリーフ・ノードに分散させることができる。

ステップＳ６０２を実施するには、様々なやり方がある可能性がある。以下、任意選択の処理方法を提供する。この処理方法は、リーフ・ノードのデータをソートすることと、ソートしたデータから予め設定した個数のデータを順番に選択して、サブリーフ・ノードにそれぞれ配置することと、それらのサブリーフ・ノードについて対応するサブノード識別子を設定することとを含む可能性がある。

サーバ・クラスタ内の各サーバのデータ処理速度およびチェックサム計算速度に従って、またサーバ・クラスタ内のサーバの個数に従って、サーバ・クラスタは、高い全体的なデータ処理効率（例えば設定された効率しきい値より高いデータ処理効率）を確保しながら各サーバが処理することができるデータの量を決定し、次いで、各サブリーフ・ノードが収容することができるデータの量またはデータの個数を決定することができる。サーバ・クラスタは、各サーバに分散されるリーフ・ノードのデータの総量を計算することもある。この場合には、サーバ・クラスタは、データがブロックチェーン・ノードに記憶された時間を示すタイムスタンプに従って分散したリーフ・ノードのデータをソートし、ソートした複数個のデータのうちの予め設定された数個のデータを順番に各サブリーフ・ノードに分散させ、データの順序に従ってサブリーフ・ノードのそれぞれについて対応するサブノード識別子を設定して、全てのサブリーフ・ノードのデータにおけるサブリーフ・ノードのデータの位置を示すようにすることができる。

例えば、サーバ・クラスタ内のサーバによって分散されたサブリーフ・ノードに、それぞれが５ＭＢであるデータを５０個格納する場合には、データ量は、２５０ＭＢとなる。各サブリーフ・ノードが収容することができるデータの量が２５ＭＢである場合には、２５０／２５＝１０であるので、１０個のサブリーフ・ノードが得られる。この場合、サブリーフ・ノードには、データの順序に従って、サブノード識別子として１〜１０の番号がつけられる。上述の処理の後で、５０個のデータの記憶位置は、次のようになる。すなわち、１番から５番のデータを、番号１のサブリーフ・ノードに順番に記憶し、６番から１０番のデータを、番号２のサブリーフ・ノードに順番に記憶し、１１番から１５番のデータを、番号３のサブリーフ・ノードに順番に記憶し、以下同様に記憶することによって、各データの記憶位置を得る。各データは５ＭＢであるので、各サブリーフ・ノードは、５個のデータを含むことができる。

ステップＳ６０３で、サーバ・クラスタは、各サブリーフ・ノードのデータのチェックサムを計算する。

実装態様では、サーバ・クラスタ内のサーバは、対応するサブリーフ・ノードを得た後で、それらのサブリーフ・ノードに記憶されているデータを得、次いで、予め設定された検査アルゴリズムを使用して各サブリーフ・ノードのチェックサムを計算することができる。例えば、サブリーフ・ノードに記憶されているデータをソートし、次いで、ソートしたデータについてＳＨＡ２５６（セキュア・ハッシュ・アルゴリズム２５６）を使用して、サブリーフ・ノードのチェックサムとしてＳＨＡ２５６値（すなわちハッシュ値）を計算することもできる。

ステップＳ６０４で、サーバ・クラスタは、各サブリーフ・ノードのデータのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算する。

実装態様では、サーバ・クラスタが各サブリーフ・ノードのチェックサムを得た後で、サブノード識別子の順序に従って、それらのサブリーフ・ノードのチェックサムをソートすることができる。次いで、サーバ・クラスタは、予め設定された検査アルゴリズムを使用してサブリーフ・ノードのチェックサムに基づく計算を集約的に実行して、対応するリーフ・ノードのチェックサムを得ることにより、ブロックチェーン・ノードによって分散されたリーフ・ノードのデータのチェックサムを得ることができる。

例えば、ステップＳ６０２の例に基づくと、ステップＳ６０３の処理によって、１０個のサブリーフ・ノードのデータそれぞれのハッシュ値を得ることができる。１つのリーフ・ノードのデータから１０個のサブリーフ・ノードのデータが分散されるので、図２に示す集約実行計算を、１０個のサブリーフ・ノードのデータの得られたハッシュ値に対して実行して、対応するリーフ・ノードのハッシュ値を得ることができる。

なお、サブリーフ・ノードの設定されたサブノード識別子によって、プル型の方式でサブリーフ・ノードのデータを得ることもできることに留意されたい。それに応じて、ステップＳ６０４の処理は、次のようになることもある。すなわち、サブリーフ・ノードのサブノード識別子、および各サブリーフ・ノードのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算する。詳細な処理については上記の関連する内容を参照すればよいので、ここでは詳細には説明しない。

ステップＳ６０５で、サーバ・クラスタは、分散したリーフ・ノードのチェックサムをブロックチェーン・ノードに送信する。

ステップＳ６０６で、ブロックチェーン・ノードは、リーフ・ノードのチェックサムに従って、リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定する。

実装態様では、ブロックチェーン・ノードのデータのルート・チェックサムは、リーフ・ノードのチェックサムに基づいて予め設定された検査アルゴリズムを使用して計算することができる。例えば、ブロックチェーン・ノードの全てのリーフ・ノードにおける記録されたノード識別子に対応するリーフ・ノードの位置に従って、Ａ−Ｂ−Ｃ−Ｆ、Ａ−Ｂ−Ｅ、およびＡ−Ｄなど、それらのリーフ・ノードで構成されるノード分散ツリー（すなわちマークル・ツリー）を得ることができる。リーフ・ノードのチェックサム（すなわちＢ＋Ｃ＋Ｄ＋Ｅ＋Ｆのチェックサム）が得られたときには、それらのリーフ・ノードのチェックサムに従ってマークル・ツリーのルート・チェックサムを計算することにより、ブロックチェーン・ノードのデータのルート・チェックサムを得ることができる。

ステップＳ６０７で、ブロックチェーン・ノードは、マークル・ツリーのルート・チェックサムを、ブロックチェーン・ノードのデータのルート・チェックサムとして指定する。

ステップＳ６０５およびステップＳ６０７の詳細なプロセスについては第１の実施形態および第２の実施形態の関連する内容を参照すればよいので、ここでは詳細には説明しない。

本願の実施形態は、データ処理方法であって、リーフ・ノードのノード識別子をサーバ・クラスタに分散させて、サーバ・クラスタに、目標ブロックチェーンのリーフ・ノードに記憶されるデータの得られた量に従って、それぞれの予め設定された個数のデータをサブリーフ・ノードに分散させることと、次いで、各サブリーフ・ノードのチェックサムを計算することと、対応するリーフ・ノードのチェックサムを決定することと、最後にそれらのリーフ・ノードのチェックサムをブロックチェーン・ノードに提供して、ブロックチェーン・ノードのデータのチェックサムを計算することとを含む、データ処理方法を提供する。このように、リーフ・ノードに記憶されるデータをサーバ・クラスタが再分散してサブリーフ・ノードを得、次いで、サブリーフ・ノードのチェックサムを計算して、そのデータが計算サーバ・クラスタに均一に分散されるようにしてチェックサムの並列計算を行うことにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証する。

第４の実施形態
図７に示すように、本願の実施形態は、データ処理方法を提供する。このデータ処理方法は、ブロックチェーン・ノードおよびサーバ・クラスタによって協働で実行されることがある。ここで、サーバ・クラスタは、図８に示すように、第１のサーバ・クラスタおよび第２のサーバ・クラスタをさらに含むことがある。図８は、データ処理システムを示している。このデータ処理システムは、２つのレベルのサーバ・クラスタ、すなわち第１のサーバ・クラスタおよび第２のサーバ・クラスタを含むことがある。ここで、第１のサーバ・クラスタは、ブロックチェーン・ノードより下位のレベルにあり、第２のサーバ・クラスタは、第１のサーバ・クラスタより下位のレベルにある。この階層構造は、データ再結合、データ分散などの目的を達成して、データ処理速度を加速させることができる。チェックサムがハッシュ値である場合を例にとって、本願の実施形態について詳細に説明する。本願の実施形態の関連する内容を参照して他の形態のチェックサムを実行することもできるが、ここでは詳細には説明しない。この方法は、以下のステップを含む可能性がある。

ステップＳ７０１で、ブロックチェーン・ノードは、事前記憶されているリーフ・ノードのノード識別子を得る。

実装態様では、ブロックチェーン・ノードにデータが記憶されると、それに応じてブロックチェーン・ノード内でリーフ・ノードが生成され、そのリーフ・ノードのノード識別子も生成される。このように、ブロックチェーンは、複数のリーフ・ノードを含むことがあり、各リーフ・ノードが、ある量のデータを記憶する。ノード識別子が生成されると、そのノード識別子を記憶することができ、ブロックチェーン・ノード内の全てのリーフ・ノードにおけるそのノード識別子に対応するリーフ・ノードの位置を記録することができる。例えば、生成されるノード識別子はＦであり、そのノード識別子に対応するリーフ・ノードの位置は、Ａ−Ｂ−Ｃ−Ｆであることがある。

ステップＳ７０２で、ブロックチェーン・ノードは、ノード識別子をサーバ・クラスタ内のサーバに送信する。

実装態様では、図８に示すシステム構造に基づいて、ブロックチェーン・ノードは、そのブロックチェーン・ノードに含まれるリーフ・ノードに記憶されるデータを得ることができ、予め開発された分散規則に従って、またはランダムに、それらのリーフ・ノードのノード識別子を１つまたは複数のグループに分割することができる。ノード識別子の各グループは、第１のサーバ・クラスタ内の１つのサーバに送信することができる。

ステップＳ７０３で、第１のサーバ・クラスタは、分散したノード識別子に従って、それらのノード識別子に対応するリーフ・ノードのデータをブロックチェーン・ノードから得る。

実装態様では、第１のサーバ・クラスタ内のサーバは、ノード識別子を含むデータ取得命令をブロックチェーン・デバイスに送信し、次いで、それらのノード識別子に対応するリーフ・ノードのデータをブロックチェーン・ノードから取り出すことができる。

ステップＳ７０４で、第１のサーバ・クラスタは、リーフ・ノードの得られたデータ量に従って、１つまたは複数のサブリーフ・ノードを生成する。

ここで、上述のように、本願の実施形態では、サブリーフ・ノードとリーフ・ノードとの間には、帰属関係、従属関係、親関係、または子関係などの関連関係はない。サブリーフ・ノードは、１つまたは複数個のデータを含むデータ・パケットであることがあり、リーフ・ノード（バケット）は、データを記憶するためのマークル・ツリー内のコンテナであることがある。

実装態様では、サブリーフ・ノードが収容することができるデータの量またはデータの個数は、例えば１００ＭＢまたは１０個など、予め設定されていることもある。第１のサーバ・クラスタの各サーバに分散されるリーフ・ノードのデータの総量は、計算することができ、各サブリーフ・ノードが収容することができるデータの量またはデータの個数に従って、１つまたは複数のサブリーフ・ノードを生成することができる。

ステップＳ７０５で、第１のサーバ・クラスタは、リーフ・ノードのデータをソートし、ソートしたデータから予め設定された個数のデータを順番に選択して、それぞれに対応するサブリーフ・ノードに配置し、それらのサブリーフ・ノードについて対応するサブノード識別子を設定する。

実装態様では、第１のサーバ・クラスタ内の任意のサーバが１つまたは複数個のデータのハッシュ値を計算するのに要する時間の長さは、反復試験方式で予め試験することができ、そこから、比較的短い時間の長さおよび比較的低いサーバの処理負荷に対応するデータの個数を選択することができる。この個数は、例えば３０個または５０個など、予め設定された数として設定されることもある。各データは、記憶またはブロックチェーン・トランザクションのプロセスにおけるタイムスタンプを備えているので、このタイムスタンプを通して、各データの記憶またはトランザクションの時間を決定することができる。このように、各データのタイムスタンプを得ることができ、それらのタイムスタンプの順序に従って、複数個のデータをソートすることができる。このソートした複数個のデータから予め設定された個数のデータを順番に選択し、対応するサブリーフ・ノードにそれぞれ分散させることができる。異なるサブリーフ・ノードの分散データの順序にラベル付けするために、分散データに基づいて、対応するサブリーフ・ノードについてサブノード識別子を設定することができる。

例えば、予め設定されるデータ数が、３個であり、リーフ・ノードのデータが、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、およびＫを含むことがある。データをタイムスタンプに従ってソートした後で、上記のデータの順序が、Ｈ−Ｇ−Ｆ−Ｅ−Ｄ−Ｃ−Ｂ−Ａ−Ｋとなることがある。この場合には、３つのデータＨ−Ｇ−Ｆを１つのサブリーフ・ノードに分散させ、３つのデータＥ−Ｄ−Ｃを１つのサブリーフ・ノードに分散させ、３つのデータＢ−Ａ−Ｋを１つのサブリーフ・ノードに分散させることができる。これら３つのサブリーフ・ノードに記憶されたデータの順序にラベル付けするために、Ｈ−Ｇ−Ｆが位置するサブリーフ・ノードのサブノード識別子を、サブノード１と設定し、Ｅ−Ｄ−Ｃが位置するサブリーフ・ノードのサブノード識別子を、サブノード２と設定し、Ｂ−Ａ−Ｋが位置するサブリーフ・ノードのサブノード識別子を、サブノード３と設定することがある。

ステップＳ７０６で、第１のサーバ・クラスタは、サブリーフ・ノードのデータを、第２のサーバ・クラスタ内のサーバに分散させる。

実装態様では、第２のサーバ・クラスタ内の各サーバの現在の残りの帯域幅および／またはデータ伝送速度などの指標データをそれぞれ得ることができる。第１のサーバ・クラスタの各サーバの計算能力は、この得られた指標データに基づいて評価することができ、この計算能力の大きさに従って、対応するサブリーフ・ノードのデータを第２のサーバ・クラスタ内のサーバに送信することができる。

さらに、計算効率を可能な限り改善するために、第２のサーバ・クラスタ内のサーバに分散されるサブリーフ・ノードの個数を調節することもある。一例では、第２のサーバ・クラスタ内の各サーバの現在の残りの帯域幅および／またはデータ伝送速度などの指標データをそれぞれ得ることができる。各サーバの計算能力は、この得られた指標データに基づいて評価することができ、この計算能力の大きさに従って、対応するサブリーフ・ノードを第２のサーバ・クラスタ内のサーバに分散されることができる。例えば、第２のサーバ・クラスタは、５つのサーバを含み、各サーバに２つのサブリーフ・ノードを分散させることがある。第２のサーバ・クラスタ内のあるサーバが最も強力な計算能力を有していると計算によって決定された場合には、上記の１０個のサブリーフ・ノードのうちの３つのデータを、このサーバに送信することができる。第２のサーバ・クラスタ内のあるサーバが最も弱い計算能力を有していると計算によって決定された場合には、上記の１０個のサブリーフ・ノードのうちの１つのデータを、このサーバに送信することができる。このようにして、生成された１つまたは複数のサブリーフ・ノードを、バランスのとれた方式で第２のサーバ・クラスタ内のサーバに提供することができる。

ステップＳ７０７で、第２のサーバ・クラスタは、各サブリーフ・ノードのハッシュ値を計算し、そのハッシュ値を第１のサーバ・クラスタ内の対応するサーバにフィード・バックする。

実装態様では、第２のサーバ・クラスタのサーバが対応するサブリーフ・ノードを受信した後で、そのサーバは、各サブリーフ・ノードのデータを抽出し、データのタイムスタンプの順序に従ってそのデータをソートすることができる。サーバは、ソートされたデータで構成された文字列を得、予め設定されたハッシュ・アルゴリズムを使用して、この文字列のハッシュ値、すなわちサブリーフ・ノードのハッシュ値を計算することができる。この方法では、第２のサーバ・クラスタは、各サブリーフ・ノードのハッシュ値を得ることができ、このハッシュ値を、その後、対応するサーバを介して、第１のサーバ・クラスタ内の対応するサーバに送信することができる。

ステップＳ７０８で、第１のサーバ・クラスタは、第２のサーバ・クラスタから送信された各サブリーフ・ノードのハッシュ値、およびそれらのサブリーフ・ノードのサブノード識別子に従って、分散したリーフ・ノードのハッシュ値を決定する。

実装態様では、第１のサーバ・クラスタ内のサーバは、第２のサーバ・クラスタから返送されたサブリーフ・ノードのチェックサムを受信した後で、各サブリーフ・ノードのサブノード識別子をそれぞれ得ることができる。次いで、これらのサーバは、各サブリーフ・ノードのサブノード識別子に従ってサブリーフ・ノードをソートすることができ、ソートしたサブリーフ・ノードのハッシュ値を収集して、サブリーフ・ノードのハッシュ値を得ることができる。例えば、サブリーフ・ノードのハッシュ値の順序がサブリーフ・ノードの順序に従って決定されることもあり、ソートされたハッシュ値が、文字列を形成することもある。文字列のハッシュ値は、予め設定されたハッシュ・アルゴリズムを用いて計算することができ、このハッシュ値が、対応するリーフ・ノードのハッシュ値となる。さらに、他のハッシュ値計算方式を使用して、リーフ・ノードのハッシュ値を決定することもできる。例えば、１つまたは複数のサブリーフ・ノードのハッシュ値の平均を、リーフ・ノードのハッシュ値として計算することもできるし、あるいは、リーフ・ノードのハッシュ値を、各サブリーフ・ノードの重みおよび各サブリーフ・ノードのハッシュ値に基づいて得ることもできる。

ステップＳ７０９で、第１のサーバ・クラスタは、分散したリーフ・ノードのハッシュ値をブロックチェーン・ノードに送信する。

ステップＳ７１０で、ブロックチェーン・ノードは、リーフ・ノードのチェックサムに従って、リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定し、このマークル・ツリーのルート・チェックサムを、ブロックチェーン・ノードのデータのルート・チェックサムとして指定する。

本願の実施形態は、データ処理方法であって、ブロックチェーン・ノードのリーフ・ノードのデータの量に従って、予め設定された個数のデータが分散された１つまたは複数のサブリーフ・ノードを生成することと、次いで、これらのサブリーフ・ノードを第２のサーバ・クラスタに分散させて、各サブリーフ・ノードのチェックサムを計算することと、各サブリーフ・ノードのチェックサムに従って対応するリーフ・ノードのチェックサムを決定することと、最後に、これらのリーフ・ノードのチェックサムをブロックチェーン・ノードに提供して、ブロックチェーン・ノードのデータのルート・チェックサムを計算することとを含む、データ処理方法を提供する。このように、リーフ・ノードに記憶されたデータを第１のサーバ・クラスタが再分散してサブリーフ・ノードを得、サブリーフ・ノードを第２のサーバ・クラスタに分散させてチェックサムを計算して、データが第２のサーバ・クラスタに均一に分散されるようにしてチェックサムの並列計算を行うことにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証する。

第５の実施形態
以上は、本願の実施形態によって提供されるデータ処理方法である。同じ概念に基づいて、本願の実施形態は、図９に示すようにデータ処理デバイスをさらに提供する。

データ処理デバイスは、上記の実施形態で提供されるブロックチェーン・ノードであることもあり、一例では、端末デバイス（例えばパーソナル・コンピュータなど）またはサーバであることもある。このデバイスは、データ分散モジュール９０１と、ルート・チェックサム取得モジュール９０２とを備える可能性があり、ここで、
データ分散モジュール９０１は、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが分散したリーフ・ノードのデータのチェックサムをそれぞれ計算するように構成され、
ルート・チェックサム取得モジュール９０２は、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムをさらに得るように構成される。

本願の実施形態では、ルート・チェックサム取得モジュール９０２は、サーバ・クラスタ内のサーバから送信されるブロックチェーン・ノードのデータのルート・チェックサムを受信するように構成される。

本願の実施形態では、ルート・チェックサム取得モジュール９０２は、リーフ・ノードのチェックサムに従って、リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定し、そのマークル・ツリーのルート・チェックサムを、ブロックチェーン・ノードのデータのルート・チェックサムとして指定するように構成される。

本願の実施形態では、データ分散モジュール９０１は、ブロックチェーン・ノードに事前記憶されているリーフ・ノードの個数に従って、予め設定された個数のリーフ・ノードのデータをサーバ・クラスタ内のサーバに送信するように構成される。

本願の実施形態では、チェックサムは、ハッシュ値である。

本願の実施形態は、データ処理デバイスであって、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散させて、サーバ・クラスタ内のサーバが、分散したリーフ・ノードのデータのチェックサムをそれぞれ計算するようにし、さらに、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成された、データ処理デバイスを提供する。このように、リーフ・ノードのデータがサーバ・クラスタに分散され、次いで分散したリーフ・ノードのデータのチェックサムがサーバ・クラスタ内の各サーバによって計算されるので、データをサーバ・クラスタに分散させて、リーフ・ノードのデータのチェックサムの並列計算を行うことができ、それにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証することができる。

第６の実施形態
同じ概念に基づいて、本願の実施形態は、図１０に示すようにデータ処理デバイスをさらに提供する。

このデータ処理デバイスは、上記の実施形態で提供されるサーバ・クラスタであることもあり、このデバイスは、データ受信モジュール１００１と、チェックサム取得モジュール１００２とを含むことがあり、ここで、
データ受信モジュール１００１は、ブロックチェーン・ノードによって分散されるリーフ・ノードのデータを受信するように構成され、
チェックサム取得モジュール１００２は、分散したリーフ・ノードのデータのチェックサムを計算して、ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成される。

本願の実施形態では、このデバイスは、
リーフ・ノードのデータ量に従って、リーフ・ノードのデータを予め設定されたサブリーフ・ノードに分散させるように構成されたデータ分散モジュールと、
各サブリーフ・ノードのデータのチェックサムを計算するように構成された計算モジュールと、をさらに含み、
それに応じて、チェックサム取得モジュール１００２は、各サブリーフ・ノードのデータのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するように構成される。

本願の実施形態では、データ分散モジュールは、リーフ・ノードのデータをソートし、ソートしたデータから予め設定された個数のデータを順番に選択して、サブリーフ・ノードにそれぞれ配置し、それらのサブリーフ・ノードについて対応するサブノード識別子を設定するように構成され、
それに応じて、チェックサム取得モジュール１００２は、サブリーフ・ノードのサブノード識別子、および各サブリーフ・ノードのチェックサムに従って、分散したリーフ・ノードのデータのチェックサムを計算するように構成される。

本願の実施形態では、チェックサム取得モジュール１００２は、分散したリーフ・ノードのデータのチェックサムを計算し、その分散したリーフ・ノードのデータのチェックサムをブロックチェーン・ノードに送信して、そのブロックチェーン・ノードが、リーフ・ノードのデータのチェックサムに従ってブロックチェーン・ノードのデータのルート・チェックサムを計算するように構成される、あるいは、分散したリーフ・ノードのデータのチェックサムを計算し、その分散したリーフ・ノードのデータのチェックサムに基づいてブロックチェーン・ノードのデータのルート・チェックサムを得、そのルート・チェックサムをブロックチェーン・ノードに送信するように構成される。

本願の実施形態は、データ処理デバイスであって、ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータをサーバ・クラスタ内のサーバに分散して、サーバ・クラスタ内のサーバが、分散したリーフ・ノードのデータのチェックサムをそれぞれ計算するようにし、さらに、サーバ・クラスタ内のサーバによって計算されたリーフ・ノードのデータのチェックサムに従って、ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成された、データ処理デバイスを提供する。このように、リーフ・ノードのデータがサーバ・クラスタに分散され、次いで分散したリーフ・ノードのデータのチェックサムがサーバ・クラスタ内の各サーバによって計算されるので、データをサーバ・クラスタに分散させて、リーフ・ノードのデータのチェックサムの並列計算を行うことができ、それにより、計算プロセスにかかる時間を短縮し、計算効率を改善し、ブロックの正常な生成およびブロックチェーンの正常な動作を保証することができる。

１９９０年代には、技術の改良は、ハードウェアの改良（例えば、ダイオード、トランジスタ、スイッチなど、回路構造の改良）、またはソフトウェアの改良（方法フローの改良）に明確に区別することができる。しかし、技術の発展とともに、方法フローに関する現在の改良の多くは、ハードウェア回路構造への直接的な改良と考えられることもある。設計者は、ほとんどの場合、改良した方法フローをハードウェア回路にプログラムすることによって、対応するハードウェア回路構造を得る。したがって、方法フローの改良をハードウェア・モジュールによって実現することはできないと結論づけることはできない。例えば、プログラマブル・ロジック・デバイス（ＰＬＤ）（例えばフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ））は、ユーザがそのデバイスをプログラムすることによってその論理的機能が決定される集積回路である。設計者は、デジタル・システムを１つのＰＬＤに「統合」するように自分でプログラムし、チップ製造者に専用のＩＣチップを設計して製造するように依頼する必要がない。現在では、さらに、この種のプログラミングは、手作業でＩＣチップを製造するより、「論理コンパイラ」ソフトウェアによってほとんど実施されている。論理コンパイラ・ソフトウェアは、プログラムの開発および書込みに使用されるソフトウェア・コンパイラと同様であるが、コンパイルする前にソース・コードを書き込むために、ハードウェア記述言語（ＨＤＬ）と呼ばれる特定のプログラミング言語を使用しなければならない。ＨＤＬは、１つだけでなく、ＡＢＥＬ（Ａｄｖａｎｃｅｄ Ｂｏｏｌｅａｎ Ｅｘｐｒｅｓｓｉｏｎ Ｌａｎｇｕａｇｅ）、ＡＨＤＬ（Ａｌｔｅｒａ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、Ｃｏｎｆｌｕｅｎｃｅ、ＣＵＰＬ（Ｃｏｒｎｅｌｌ Ｕｎｉｖｅｒｓｉｔｙ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ）、ＨＤＣａｌ、ＪＨＤＬ（Ｊａｖａ（登録商標） Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、Ｌａｖａ、Ｌｏｌａ、ＭｙＨＤＬ、ＰＡＬＡＳＭ、ＲＨＤＬ（Ｒｕｂｙ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）など、多数の種類が存在する。現在最も一般的に使用されるものとしては、ＶＨＤＬ（Ｖｅｒｙ−Ｈｉｇｈ−Ｓｐｅｅｄ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）およびＶｅｒｉｌｏｇが挙げられる。当業者なら、ハードウェア回路を得て、上記のＨＤＬを使用してある程度の論理プログラミングを方法フローについて行い、その方法フローをＩＣにプログラムすることによって論理方法フローを実施すると非常に容易であることも気づくべきであろう。

制御装置は、任意の適当な方式で実装することができる。例えば、制御装置は、例えばマイクロプロセッサまたはプロセッサの形態であってもよいし、（マイクロ）プロセッサ、論理ゲート、スイッチ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル・ロジック・コントローラ、および埋込み型マイクロコントローラによって実行することができるコンピュータ可読プログラム・コード（例えばソフトウェアまたはファームウェア）を記憶するコンピュータ可読媒体の形態であってもよい。制御装置の例としては、これらに限定されるわけではないが、ＡＲＣ社製６２５Ｄ、Ａｔｍｅｌ社製ＡＴ９１ＳＡＭ、Ｍｉｃｒｏｃｈｉｐ社製ＰＩＣ１８Ｆ２６Ｋ２０、およびＳｉｌｉｃｏｎｅ Ｌａｂｓ社製Ｃ８０５１Ｆ３２０などのマイクロコントローラが挙げられる。メモリ制御装置は、さらに、メモリの制御論理の一部として実装されることもある。当業者なら、制御装置が純粋にコンピュータ可読プログラム・コードによって実装されるだけでなく、方法のステップについて論理プログラミングを実行して、制御装置が、同じ機能を論理ゲート、スイッチ、ＡＳＩＣ、プログラマブル・ロジック・コントローラ、埋込み型マイクロコントローラなどの形態で実施することも完全に可能であることも気づくべきであろう。したがって、このような制御装置は、ハードウェア部品とみなされることもあるが、その制御装置に含まれ、様々な機能を実現するように構成されたデバイスが、そのハードウェア部品の内部の構造とみなされることもある。あるいは、様々な機能を実現するように構成されたデバイスは、方法を実施するソフトウェア・モジュール、およびハードウェア部品の内部の構造の両方とみなされることもある。

上記の実施形態で説明したシステム、装置、モジュール、またはユニットは、コンピュータ・チップまたはエンティティによって実装することも、あるいは機能を有する製品によって実装することもできる。代表的な実装デバイスは、コンピュータである。一例では、コンピュータは、例えば、パーソナル・コンピュータ、ラップトップ・コンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、携帯情報端末、メディア・プレイヤ、ナビゲーション・デバイス、電子メール・デバイス、ゲーム・コンソール、タブレット・コンピュータ、ウェアラブル・デバイス、またはこれらのデバイスのうちの任意のデバイスの組合せである可能性がある。

説明の便宜上、上記のデバイスは、説明のための機能に応じて様々なユニットに分割されている。これらのユニットの機能は、本願を実施するときには、１つまたは複数のソフトウェアおよび／またはハードウェアで実装される可能性がある。

当業者なら、本発明の実施形態が、方法、システム、またはコンピュータ・プログラム製品として提供される可能性があることを理解されたい。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態として実施される可能性がある。さらに、本発明は、コンピュータ使用可能プログラム・コードを含む１つまたは複数のコンピュータ使用可能記憶媒体（これらに限定されるわけではないが、磁気ディスク・メモリ、ＣＤ−ＲＯＭ、光メモリなど）に実装されたコンピュータ・プログラム製品の形態である可能性もある。

本発明の実施形態による方法、デバイス（システム）、およびコンピュータ・プログラム製品の流れ図および／またはブロック図を参照して、本発明について説明した。コンピュータ・プログラム命令を使用して、これらの流れ図および／またはブロック図の各プロセスおよび／またはブロック、ならびにこれらの流れ図および／またはブロック図のプロセスおよび／またはブロックの組合せを実施することもできることを理解されたい。これらのコンピュータ・プログラム命令を、汎用コンピュータ、特殊目的コンピュータ、埋込み型プロセッサ、またはその他のプログラマブル・データ処理デバイスのプロセッサに提供してマシンを生成し、これらの命令がコンピュータまたは他のプログラマブル・データ処理デバイスのプロセッサによって実行されることによって、流れ図の１つもしくは複数のプロセスおよび／またはブロック図の１つもしくは複数のブロックに指定される機能を実施する装置を生成することができる。

これらのコンピュータ・プログラム命令を、コンピュータまたはその他のプログラマブル・データ処理デバイスに特定の方式で動作するように命令することができるコンピュータ可読メモリに記憶して、コンピュータ可読メモリに記憶された命令が命令装置を含む製品を生成することもできる。命令装置は、流れ図の１つまたは複数のプロセス、および／あるいはブロック図の１つまたは複数のブロックに指定される機能を実施する。

これらのコンピュータ・プログラム命令は、コンピュータまたはその他のプログラマブル・データ処理デバイスにロードされて、一連の動作ステップをコンピュータまたはその他のプログラマブル・デバイス上で実行させることによって、コンピュータ実施処理を生成することもできる。したがって、コンピュータまたはその他のプログラマブル・デバイス上で実行される命令は、流れ図の１つまたは複数のプロセス、および／あるいはブロック図の１つまたは複数のブロックに指定される機能を実施するステップを提供する。

代表的な構成では、計算デバイスは、１つまたは複数のプロセッサ（ＣＰＵ）と、入出力インタフェースと、ネットワーク・インタフェースと、メモリとを含む。

メモリは、例えば読取り専用メモリ（ＲＯＭ）またはフラッシュＲＡＭなど、揮発性メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、および／または不揮発性メモリなどのコンピュータ可読媒体を含む可能性がある。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、任意の方法または技術によって情報の記憶を実施することができる、永続的媒体、揮発性媒体、可動媒体、および固定媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラム・モジュール、またはその他のデータである可能性がある。コンピュータの記憶媒体の例としては、これらに限定されるわけではないが、計算デバイスがアクセスできる情報を記憶するために使用することができる、相変化ランダム・アクセス・メモリ（ＰＲＡＭ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、動的ランダム・アクセス・メモリ（ＤＲＡＭ）、その他のタイプのランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリまたはその他のメモリ技術、コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）またはその他の光メモリ、カセット、カセットおよびディスク・メモリまたはその他の磁気メモリデバイス、あるいはその他の任意の非伝送媒体などが挙げられる。本明細書の定義によれば、コンピュータ可読媒体は、変調データ信号および搬送波などの一時的媒体を含まない。

さらに、「含む」または「備える」という用語、あるいはこれらの用語のその他の変形語は、非排他的な包含を含むものとして意図されており、それにより、一連の要素を含むプロセス、方法、物品、またはデバイスが、それらの要素を含むだけでなく、明示的には列挙されていない他の要素も含む、あるいはそのプロセス、方法、物品、またはデバイスに固有の要素をさらに含むことにも留意されたい。さらなる制約がないときには、各要素が「１つの…を含む」という記述によって定義されていることは、当該要素を含むプロセス、方法、物品、またはデバイスが、同種の要素をさらに含むことを排除しない。

当業者なら、本願の実施形態が、方法、システム、またはコンピュータ・プログラム製品として提供される可能性があることを理解されたい。したがって、本願は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態として実施される可能性がある。さらに、本願は、コンピュータ使用可能プログラム・コードを含む１つまたは複数のコンピュータ使用可能記憶媒体（これらに限定されるわけではないが、磁気ディスク・メモリ、ＣＤ−ＲＯＭ、光メモリなど）に実装されたコンピュータ・プログラム製品の形態である可能性もある。

本願は、プログラム・モジュールなどコンピュータによって実行されるコンピュータ実行可能命令の一定の文脈で説明されることがある。一般に、プログラム・モジュールは、特定のタスクを実行するため、または特定の抽象データ型を実施するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本願は、分散型コンピューティング環境で実施されることもある。こうした分散型コンピューティング環境では、通信ネットワークを介して接続された遠隔処理デバイスがタスクを実行する。分散型コンピューティング環境では、プログラム・モジュールは、ストレージ・デバイスなど、ローカルおよび遠隔のコンピュータ記憶媒体に位置することがある。

本願の実施形態は、各実施形態において他の実施形態との相違点に注目するようにして漸進的に説明しており、これらの実施形態は、同じ、または類似の部分については相互に参照することができる。特に、システムの実施形態は、比較的簡単に説明しているが、これは、システムの実施形態が、方法の実施形態と実質的に同様であるからである。関連する部分については、方法の実施形態の説明を参照すればよい。

以上は、本願の実施形態に過ぎず、本願を限定するために使用されるものではない。当業者にとっては、本願は、様々な修正および変更を有する可能性がある。本願の趣旨および原理の範囲内で行われる任意の修正、等価な置換、または改良は、本願の特許請求の範囲に含まれるものとする。

Claims (16)

1. データ処理方法であって、
   ブロックチェーン・ノードが、前記ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータを第１のサーバ・クラスタ内の複数のサーバに分散させるステップと、
   前記第１のサーバ・クラスタ内のサーバが、前記分散されたリーフ・ノードのデータ量に応じて、前記分散されたリーフ・ノードのデータを複数のサブリーフ・ノードに均一に再分散させるステップと、
   第２のサーバ・クラスタ内の複数のサーバが、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムを並列に計算するステップと、
   前記第１のサーバ・クラスタ内の前記サーバが、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムに従って、前記分散されたリーフ・ノードのデータのチェックサムを計算するステップと、
   前記ブロックチェーン・ノードが、前記第１のサーバ・クラスタ内の前記複数のサーバによって計算された前記分散されたリーフ・ノードの前記データの前記チェックサムに従って、前記ブロックチェーン・ノードのデータのルート・チェックサムを得るステップと、を含む、データ処理方法。
2. 前記第１のサーバ・クラスタ内の前記複数のサーバによって計算された前記分散されたリーフ・ノードの前記データの前記チェックサムに従って、前記ブロックチェーン・ノードのデータのルート・チェックサムを得る前記ステップが、
   前記第１のサーバ・クラスタ内の前記複数のサーバから送信された前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムを受信するステップを含む、請求項１に記載の方法。
3. 前記第１のサーバ・クラスタ内の前記複数のサーバによって計算された前記分散されたリーフ・ノードの前記データの前記チェックサムに従って、前記ブロックチェーン・ノードのデータのルート・チェックサムを得る前記ステップが、
   前記リーフ・ノードの前記チェックサムに従って、前記リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定するステップと、
   前記マークル・ツリーの前記ルート・チェックサムを、前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムとして指定するステップと、を含む、請求項１に記載の方法。
4. 前記ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータを第１のサーバ・クラスタ内の複数のサーバに分散させる前記ステップが、
   前記ブロックチェーン・ノードに事前記憶されている前記リーフ・ノードの個数に従って、予め設定された個数のリーフ・ノードのデータを前記第１のサーバ・クラスタ内の複数のサーバにそれぞれ送信するステップを含む、請求項１に記載の方法。
5. 前記チェックサムが、ハッシュ値である、請求項１から４のいずれか１項に記載の方法。
6. データ処理方法であって、
   第１のサーバ・クラスタ内のサーバが、ブロックチェーン・ノードによって分散されたリーフ・ノードのデータを受信するステップと、
   前記第１のサーバ・クラスタ内のサーバが、前記分散されたリーフ・ノードのデータ量に応じて、前記分散されたリーフ・ノードのデータを複数のサブリーフ・ノードに均一に再分散させるステップと、
   第２のサーバ・クラスタ内の複数のサーバが、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムを並列に計算するステップと、
   前記第１のサーバ・クラスタ内の前記サーバが、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムに従って、前記分散されたリーフ・ノードの前記データのチェックサムを計算して、前記ブロックチェーン・ノードが、前記ブロックチェーン・ノードのデータのルート・チェックサムを得るステップと、を含む、データ処理方法。
7. 前記分散されたリーフ・ノードのデータを複数のサブリーフ・ノードに均一に再分散させる前記ステップが、
   前記リーフ・ノードの前記データをソートするステップと、
   前記ソートしたデータから予め設定された個数のデータを順番に選択して、前記サブリーフ・ノードに配置するステップと、
   前記サブリーフ・ノードについて、対応するサブノード識別子を設定するステップとを含み、
   前記分散されたリーフ・ノードの前記データの前記チェックサムを計算する前記ステップが、
   前記サブリーフ・ノードの前記サブノード識別子、および前記サブリーフ・ノードのそれぞれの前記チェックサムに従って、前記分散したリーフ・ノードの前記データの前記チェックサムを計算するステップを含む、請求項６に記載の方法。
8. 前記分散されたリーフ・ノードの前記データのチェックサムを計算して、前記ブロックチェーン・ノードのデータのルート・チェックサムを得る前記ステップが、
   前記分散したリーフ・ノードの前記データの前記チェックサムを計算し、前記分散したリーフ・ノードの前記データの前記チェックサムを前記ブロックチェーン・ノードに送信して、前記ブロックチェーン・ノードが、前記リーフ・ノードの前記データの前記チェックサムに従って前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムを計算するステップ、または
   前記分散したリーフ・ノードの前記データの前記チェックサムを計算し、前記分散したリーフ・ノードの前記データの前記チェックサムに基づいて前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムを得、前記ルート・チェックサムを前記ブロックチェーン・ノードに送信するステップを含む、請求項６に記載の方法。
9. データ処理デバイスであって、
   ブロックチェーン・ノードに事前記憶されているリーフ・ノードのデータを第１のサーバ・クラスタ内の複数のサーバに分散させて、
   前記第１のサーバ・クラスタ内のサーバに、前記分散されたリーフ・ノードのデータ量に応じて、前記分散されたリーフ・ノードのデータを複数のサブリーフ・ノードに均一に再分散させ、
   第２のサーバ・クラスタ内の複数のサーバに、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムを並列に計算させ、
   前記第１のサーバ・クラスタ内の前記サーバに、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムに従って、前記分散されたリーフ・ノードの前記データのチェックサムをそれぞれ計算させる
   ように構成されたデータ分散モジュールと、
   前記第１のサーバ・クラスタ内の前記複数のサーバによって計算された前記分散されたリーフ・ノードの前記データの前記チェックサムに従って、前記ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成されたルート・チェックサム取得モジュールと、を備える、データ処理デバイス。
10. 前記ルート・チェックサム取得モジュールが、前記第１のサーバ・クラスタ内の前記複数のサーバから送信された前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムを受信するように構成される、請求項９に記載のデバイス。
11. 前記ルート・チェックサム取得モジュールが、前記リーフ・ノードの前記チェックサムに従って、前記リーフ・ノードに対応するマークル・ツリーのルート・チェックサムを決定し、前記マークル・ツリーの前記ルート・チェックサムを、前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムとして指定するように構成される、請求項９に記載のデバイス。
12. 前記データ分散モジュールが、前記ブロックチェーン・ノードに事前記憶されている前記リーフ・ノードの個数に従って、予め設定された個数のリーフ・ノードのデータを前記第１のサーバ・クラスタ内の複数のサーバにそれぞれ送信するように構成される、請求項９に記載のデバイス。
13. 前記チェックサムが、ハッシュ値である、請求項９から１２のいずれか１項に記載のデバイス。
14. データ処理デバイスであって、
    第１のサーバ・クラスタ内のサーバが、ブロックチェーン・ノードによって分散されたリーフ・ノードのデータを受信するように構成されたデータ受信モジュールと、
    前記第１のサーバ・クラスタ内のサーバが、前記分散されたリーフ・ノードのデータ量に応じて、前記分散されたリーフ・ノードのデータを複数のサブリーフ・ノードに均一に再分散させるように構成されたデータ分散モジュールと、
    第２のサーバ・クラスタ内の複数のサーバが、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムを並列に計算するように構成された計算モジュールと、
    前記第１のサーバ・クラスタ内の前記サーバが、前記再分散された複数のサブリーフ・ノードのデータの各チェックサムに従って、前記分散されたリーフ・ノードの前記データのチェックサムを計算して、前記ブロックチェーン・ノードが、前記ブロックチェーン・ノードのデータのルート・チェックサムを得るように構成されたチェックサム取得モジュールと、を備える、データ処理デバイス。
15. 前記データ分散モジュールが、前記リーフ・ノードの前記データをソートし、前記ソートしたデータから予め設定された個数のデータを順番に選択して、前記サブリーフ・ノードに配置し、前記サブリーフ・ノードについて、対応するサブノード識別子を設定するように構成され、
    前記チェックサム取得モジュールが、前記サブリーフ・ノードの前記サブノード識別子、および前記サブリーフ・ノードのそれぞれの前記チェックサムに従って、前記分散したリーフ・ノードの前記データの前記チェックサムを計算するように構成される、請求項１４に記載のデバイス。
16. 前記チェックサム取得モジュールが、前記分散したリーフ・ノードの前記データの前記チェックサムを計算し、前記分散したリーフ・ノードの前記データの前記チェックサムを前記ブロックチェーン・ノードに送信して、前記ブロックチェーン・ノードが、前記リーフ・ノードの前記データの前記チェックサムに従って前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムを計算するように構成される、または
    前記分散したリーフ・ノードの前記データの前記チェックサムを計算し、前記分散したリーフ・ノードの前記データの前記チェックサムに基づいて前記ブロックチェーン・ノードの前記データの前記ルート・チェックサムを得、前記ルート・チェックサムを前記ブロックチェーン・ノードに送信するように構成される、請求項１４に記載のデバイス。

Images