JP2022547956A - ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法 - Google Patents

Abstract

本出願は、ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法を開示する。当該方法では、まず、ブロックをブロックファイルに永続化し、１層目インデックスデータをインデックスデータベースに永続化し、次に照会条件に応じて、合致した取引位置を取得し、最後にブロックファイルから完全な取引を得る。本出願では、ブロックチェーンデータの格納処理プロセスを拡張し、ブロックチェーンインデックスデータを独立したインデックスデータベースに格納し、かつマルチデータベーストランザクションの原子性を確保することで、ビジネス情報を取引ノートフィールドにカスタマイズし、次に取引ノートインデックスフィールドをカスタマイズすることによって取引とビジネス情報を関連付け、最後に取引キー情報に基づいて完全な取引のデータインデックスを取得する仕組みが確立され、それに、ブロックチェーン上のブロックを再トラバースして解析することなく、特定の取引を迅速にインデックスすることができるため、ブロックチェーン取引のトレーサビリティーの効率が大幅に向上し、同時に、データの信頼性が確保され、取引データのトレーサビリティーの基礎が築かれる。

Description

本出願は、ブロックチェーンの技術分野に属し、特に、ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法に関する。

［関連出願の相互参照］
本出願は、２０２０年０５月１８日に提出され、「ブロックチェーンデータをインデックスする方法」と題された中国特許出願第２０２０１０４１９３６４．９号の優先権を主張し、そのすべての内容は参照により本出願に組み込まれている。

ブロックチェーン技術の急速な発展と普及に伴い、ブロックチェーンの技術研究およびその派生応用も爆発的な成長を呈している。ブロックチェーンデータは、改ざん防止、データの検証、データの追跡が可能であり、スマート・ガバメント、スマート・ヘルスケア、チャリティ・トラッキングやエビデンス・トレーサビリティを実現するための中核的な最先端技術となっている。既存のブロックチェーンシステムでは、一般的にＫｅｙ－Ｖａｌｕｅ型のデータベースストレージエンジンとファイルストレージのハイブリッドストレージアーキテクチャを採用しており、ブロックや取引などの連続したデータはファイルに、その他のデータはＫｅｙ－Ｖａｌｕｅ型のＮｏＳＱＬデータベースに格納されている。そのため、データの検索において、Ｋｅｙ値に基づいた粗視化照会しかできず、Ｖａｌｕｅの構造化されたデータを検索することができない。例えば、ある口座の取引をすべて照会したい場合、ブロックチェーン全体をトラバースし、ブロック番号をＫｅｙとして対応するＶａｌｕｅを取得し、ブロックの内容をデシリアライズした上で、取引送信者と取引受信者が両方とも指定された口座の取引をスクリーニングする必要がある。このような照会方法は効率が極めて低いため、実用性を有しない。別の例として、特定のビジネスアプリケーションに関連する取引をスクリーニングしたいユーザーは、ビジネスデータではなく、取引受信者（つまり契約アドレス）のみに基づいて行うことができ、これはユーザーにとって十分に直感的ではない。

この問題を解決するために、既存の解決手段には次の２つがある：１．リレーショナルデータベースをオフチェーンで展開して、ブロックチェーン上のデータをリアルタイムに同期させ、ブロックチェーンから同期したデータを構造化して格納する。２．基盤となるブロックチェーンシステムのストレージアーキテクチャとしてリレーショナルデータベースを使用する。前者は、データの同期効率が悪く、リアルタイム性に欠け、余分な冗長ストレージオーバーヘッドを追加し、かつオフチェーンデータベースからの照会は、既にブロックチェーンから外れており、データの信頼性を有しない。後者は、ブロックチェーンブロックデータ、取引データを構造化し、リレーショナルデータベースに格納するが、既存のＫｅｙ－Ｖａｌｕｅ型に基づくストレージアーキテクチャでは、改良のコストが高く、ＮｏＳＱＬほどの性能を発揮できない。

どのようにして既存のストレージアーキテクチャを拡張し、冗長ストレージオーバーヘッドを最小限に抑え、システムのスループットへの影響を軽減することを前提に、既存のブロックチェーンシステムに、Ｖａｌｕｅに基づく照会をサポートさせ、さらに特定のビジネスに関連する取引への高速検索をサポートさせるかは、ブロックチェーンをトレーサビリティのシナリオで広く応用するために関心する必要がある重要な問題となっている。本出願は、従来技術の欠陥に対応するために、ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法を提供することを目的とする。

本出願の目的は、以下の技術的解決手段によって達成される。つまり、ブロックチェーンデータをインデックスする方法であり、
（１）ブロックチェーンクライアントが、ブロックチェーン取引を生成して検証ノードに送信するステップと、ここで、前記ブロックチェーン取引は、取引送信者、取引受信者、取引生成時間、取引ノートおよび取引ノートインデックスを含み、前記取引ノートインデックスのデータタイプは、数値、文字列または配列であり、前記配列は、数値、文字列のうちの少なくとも１つで構成され、配列の要素は順序付けられており、
（２）検証ノードがステップ（１）で送信された取引を受信すると、コンセンサス生成ブロックがブロックを生成した後にブロックを実行し、次にブロックに含まれる各取引の取引キー情報を抽出して取引キー情報リストを構成し、１層目インデックスデータを構築するステップと、ここで、前記１層目インデックスデータは、ブロック番号および取引キー情報リストを含み、前記取引キー情報は、取引送信者、取引受信者、取引生成時間、取引ノートインデックス、およびブロックにおける取引の位置を含み、
（３）検証ノードは、ステップ（２）で生成されたブロックをブロックファイルに永続化し、ステップ（２）で構築された１層目インデックスデータをインデックスデータベースに永続化するステップと、
（４）クライアントが、照会条件と検索モードを含む照会要求を検証ノードに送信するステップと、ここで、前記照会条件は、指定された取引送信者、取引受信者、取引生成時間、取引ノートインデックスのうちの１つ以上で構成され、前記検索モードは、複数条件ＡＮＤ照会、複数条件ＯＲ照会、取引ノートインデックスに基づく順次正確な照会、取引ノートインデックスに基づく非順次正確な照会、および取引ノートインデックスに基づく非順次一致照会を含み、
（５）検証ノードは、ステップ（４）でクライアントが送信した照会要求の検索モードに応じて、ステップ（３）で得られたインデックスデータベースから、照会条件に合致する取引キー情報に対応するブロック番号およびブロックにおける取引の位置を取得し、ステップ（３）で得られたブロックファイルに照会して完全な取引を取得し、クライアントに返信するステップと、を含む。

さらに、照会条件が取引ノートインデックスのみを含み、かつ指定された配列である場合、前記検索モードは、取引ノートインデックスに基づく順次正確な照会、取引ノートインデックスに基づく非順次正確な照会または取引ノートインデックスに基づく非順次一致照会から選択され、照会条件がそれ以外の場合、前記検索モードは、複数条件ＡＮＤ照会、または複数条件ＯＲ照会から選択される。

さらに、前記複数条件ＡＮＤ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件のすべての項目に合致するものであり、前記複数条件ＯＲ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件の少なくとも１項目に合致するものであり、ここで、特定の取引の取引キー情報に含まれる取引送信者、取引受信者または取引生成時間が、照会条件で指定された取引送信者、取引受信者または取引生成時間と同様である場合、当該取引の取引キー情報が照会条件の対応する１項目に合致することを示し、照会条件で指定された取引ノートインデックスが配列である場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示し、照会条件で指定された取引ノートインデックスが配列ではない場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの数値または文字列と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示す。

さらに、前記取引ノートインデックスに基づく順次正確な照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であるということであり、前記取引ノートインデックスに基づく非順次正確な照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素と同様であるということであり、前記取引ノートインデックスに基づく非順次一致照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素の少なくとも１つを含むということである。

さらに、ステップ（３）で得られたインデックスデータベースにおける１層目インデックスデータに含まれる特定のフィールドに対して、ネイティブデータベースインデックスを２層目インデックスとして作成し、検証ノードが新規取引で構築された１層目インデックスデータをインデックスデータベースに永続化する際に、２層目インデックスを自動的に更新する。

さらに、前記２層目インデックスは、全インデックスまたは部分インデックスであり、前記全インデックスとは、インデックスデータベースにおける各１層目インデックスデータの特定のフィールドに対してネイティブデータベースインデックスを作成することを意味し、前記部分インデックスとは、１層目インデックスデータの特定のフィールドに対して、インデックスデータベースにおける１層目インデックスデータの一部を選択してその特定のフィールドのネイティブデータベースインデックスを作成し、つまり、部分インデックスを作成する際に、どの１層目のインデックスデータに対して２層目インデックスを作成し、どの１層目のインデックスデータに対して２層目インデックスを作成しないかを指定するためのフィルタ式を追加することを意味する。

さらに、前記取引ノートは、ブロックチェーンクライアントによってカスタマイズされた任意の取引関連データであり、前記取引ノートインデックスは、ブロックチェーンクライアントによってカスタマイズされた任意の取引関連インデックスである。

さらに、前記配列の要素は、３０個以下である。

さらに、前記文字列は、１０２４ビット以下である。

さらに、前記ブロックファイルは、Ｋｅｙ－Ｖａｌｕｅ型照会をサポートし、前記インデックスデータベースは、ＳＱＬ様照会をサポートする非リレーショナルデータベースを使用する。

ブロックチェーンデータを格納する方法であって、前記格納方法が検証ノードに適用され、前記格納方法は、
取引送信者、取引受信者、取引生成時間、取引ノートおよび取引ノートインデックスを含むブロックチェーン取引を取得することと、
前記ブロックチェーン取引に応じて、コンセンサス生成ブロックがブロックを生成した後に前記ブロックを実行することと、
前記ブロックのブロック番号を取得し、かつ前記ブロックにおける各取引の、取引送信者、取引受信者、取引生成時間、取引ノートインデックス、ブロックにおける取引の位置を含む取引キー情報を抽出することと、
前記取引キー情報および前記ブロック番号に応じて、１層目インデックスデータを構築することと、
前記１層目インデックスデータをインデックスデータベースに永続化することと、
前記ブロックをブロックファイルに永続化することと、を含む。

本出願では、ブロックチェーンデータの格納処理プロセスを拡張し、ブロックチェーンインデックスデータを独立したインデックスデータベースに格納し、かつマルチデータベーストランザクションの原子性を確保することで、ビジネス情報を取引ノートフィールドにカスタマイズし、次に取引ノートインデックスフィールドをカスタマイズすることによって取引とビジネス情報を関連付け、最後に取引キー情報に基づいて完全な取引のデータインデックスを取得する仕組みが確立される。ブロックチェーン上のブロックを再トラバースして解析することなく、特定の取引を迅速にインデックスすることができるため、ブロックチェーン取引のトレーサビリティーの効率が大幅に向上し、また、データはブロックチェーン以外のデータベースではなく、ブロックチェーンの台帳から由来するため、データの信頼性が確保され、取引データのトレーサビリティーの基礎が築かれる。

本出願の技術的解決手段をより明確に説明するために、以下では、実施例または従来技術の説明で使用される図面を簡単に紹介する。当然のことながら、以下の説明における図面は、本出願のいくつかの実施例に過ぎず、当業者であれば、創造的労働を要することなく、これらの図面に基づく他の図面を得ることができる。

本出願の実施例が提供するブロックチェーンデータをインデックスする方法のフロー図である。 本出願の実施例が提供するブロックチェーンデータをインデックスする方法における１層目インデックスデータの構造を示す概略図である。 本出願の実施例が提供するブロックチェーンデータをインデックスする方法におけるデータの流れを示す概略図である。 本出願の実施例が提供するブロックチェーンに基づく銀行間振込サービスシステムのアーキテクチャ図である。

以下では、図面および具体的な実施例に基づいて本出願を詳細に説明することで、本出願の目的と効果がより明らかになる。

［実施例１］
ブロックチェーンデータをインデックスする方法であって、具体的には、図１に示すように、以下のステップＳ１、Ｓ２、Ｓ３、Ｓ４を含む。

Ｓ１、ブロックチェーンクライアントが、ブロックチェーン取引を生成して検証ノードに送信する。

前記ブロックチェーン取引は、取引送信者と取引受信者を含む取引参加者、取引生成時間、取引ノート情報および取引ノートインデックス情報を含む。ここで、取引ノート情報フィールドと取引ノートインデックス情報フィールドは、本出願が既存の取引データの構造を拡張したものである。

前記取引ノート情報フィールドは、クライアントによってカスタマイズされた任意のビジネス関連データ、例えば、デポジットハッシュ、商品情報、著作権情報などである。

前記取引ノートインデックス情報フィールドは、クライアントによってカスタマイズされた任意のビジネス関連インデックス情報であり、そのデータタイプは、数値、文字列（１０２４ビット以下）または配列であり、前記配列は、数値、文字列の少なくとも１つで構成され、ブロックチェーン取引が複数の取引ノートインデックス情報を有することを示し、配列に含まれる要素（数値、文字列）は３０個以下であり、当該インデックス情報は、取引ノート情報フィールドに対応しても対応しなくてもよく、クライアントがどのように定義されるかによって決められる。取引ノートインデックス情報フィールドに応じて、１つ以上の特定の取引を迅速に検索し、取引で定義された完全なビジネスデータを得ることができ、例えば、取引ノートインデックスフィールドで定義された商品ＩＤに応じて、取引ノートフィールドで定義された商品詳細を得る、取引ノートインデックスフィールドで定義された商品ＩＤおよび商品追加／削除／修正／検査操作コードに応じて、取引ノートフィールドで定義された操作詳細を得る、取引ノートインデックスフィールドに格納された前回のビジネス操作に関連する取引ハッシュに応じて、前の取引をトレースするなどがある。これらの２つのフィールドの内容は完全にクライアントによって自由に定義され、ノードはその内容を気にする必要がなく、ＤＤｏＳ攻撃を防ぐためにこれらの２つのフィールドのサイズを制限するだけでよい。この設計により、クライアントはブロックチェーンの特性を利用して、所望のアプリケーションを柔軟に開発することができる。

Ｓ２、検証ノードがステップＳ１で送信された取引を受信すると、コンセンサス生成ブロックがブロックを生成した後にブロックを実行し、次にブロックデータと取引データに応じてブロックに含まれる各取引のキー情報を抽出し、１層目インデックスデータを構築する。

図２に示すように、前記１層目インデックスデータは、ブロックを単位とし、ブロック番号と取引キー情報リストの２つのフィールドを含む。前記取引キー情報リストに含まれる各取引は、いずれも取引参加者、取引生成時間、取引ノートインデックス情報、ブロックにおける取引の位置情報を含む。

Ｓ３、検証ノードは、ステップＳ２で生成されたブロックをブロックファイルに永続化し、ステップＳ２で構築された１層目インデックスデータをインデックスデータベースに永続化する。

図３に示すように、１層目インデックスデータおよび対応するブロックが、同じ検証ノードの異なるデータベースに格納される。前記ブロックは、Ｋｅｙ－Ｖａｌｕｅ型照会をサポートするブロックファイルに格納され、ここで、Ｋｅｙはブロック番号であり、Ｖａｌｕｅはブロック詳細であり、ブロックファイルは、ブロック番号に基づいてブロック詳細を得て、さらにブロック番号およびブロックにおける取引の位置に基づいて取引詳細を得ることのみをサポートしている。前記１層目インデックスデータは、インデックスデータベースに格納され、インデックスデータベースは、ＳＱＬ様照会をサポートする非リレーショナルデータベース、例えばＭｏｎｇｏＤＢである。１層目インデックスデータは、取引キー情報だけであり、インデックスデータベースに格納されるが、取引の完全な詳細情報および取引ノート情報はブロックファイルに格納されることで、インデックスデータベースの過剰な冗長格納が効果的に回避される。

インデックスデータベースとブロックファイルのデータ挿入は、トランザクションの原子性を有し、前記トランザクションの原子性とは、ノードがブロックを１つ生成するたびにデータ挿入トランザクションを生成することを意味し、複数のデータベースへの挿入は、すべてのデータベースへの新規データの挿入を成功させるか、新規データを挿入しないか、トランザクションの原子性を確保する必要がある。ブロックファイルに対するブロックの書き込みが成功し、インデックスデータベースへのデータ挿入が失敗した場合、ブロックファイルをロールバックする。インデックスデータベースに対するインデックスデータの挿入が成功し、ブロックファイルへの書き込みが失敗した場合、インデックスデータベースをロールバックする。したがって、ノードで新しいブロックが生成および格納されると、対応するインデックスデータが生成され、インデックスデータベースに格納されると考えられる。

Ｓ４、図３に示すように、クライアントが検証ノードに照会要求を送信するすると、検証ノードは、クライアントから送信された照会条件に応じて、ステップＳ３のインデックスデータベースから照会条件に合致する取引を取得し、当該取引が位置するブロックの番号およびブロックにおける取引の位置情報を得て、さらにブロック番号およびブロックにおける取引の位置情報に応じて、ステップＳ３のブロックファイルからＯ（１）時間計算量で照会して完全な取引を得て、クライアントに返信する。

前記照会要求は、照会条件および検索モードを含む。

前記照会条件は、取引送信者、取引受信者、取引生成時間、取引ノートインデックス情報条件のいずれか１つ以上で構成され、ここで、取引ノートインデックス情報が配列である場合、その中の数値または文字列は対応する順序を有する。

前記検索モードは、複数条件ＡＮＤ照会、複数条件ＯＲ照会、取引ノートインデックス情報に基づく順次正確な照会、取引ノートインデックス情報に基づく非順次正確な照会、および取引ノートインデックス情報に基づく非順次一致照会を含む。照会条件が取引ノートインデックス情報のみを含み、かつ配列である場合、検索モードは、取引ノートインデックス情報に基づく順次正確な照会、取引ノートインデックス情報に基づく非順次正確な照会、または取引ノートインデックス情報に基づく非順次一致照会から選択され、照会条件がそれ以外の場合、検索モードは、複数条件ＡＮＤ照会または複数条件ＯＲ照会から選択される。

前記複数条件ＡＮＤ照会は、検証ノードが、取引情報が照会条件に完全に合致する取引をインデックスデータベースから検索するものであり、すなわち、照会条件が取引送信者、取引受信者または取引生成時間を含む場合、それに対応して、検索された取引情報に含まれる取引送信者フィールド、取引受信者フィールド、および取引生成時間フィールドの値が、照会条件で指定された取引送信者、取引受信者および取引生成時間の値と等しくなり、照会条件が取引ノートインデックス情報条件を含む場合、それに対応して、検索された取引情報に含まれる取引ノートインデックスフィールドが、照会条件で指定された取引ノートインデックス値と等しくなり、それに対応して、照会条件で指定された取引ノートインデックス値が配列である場合、検索された取引情報の取引ノートインデックスフィールド値も配列であり、かつ配列の要素値および要素順序が照会条件で指定された配列と完全に一致する。

前記複数条件ＯＲ照会は、検証ノードが、取引情報の一部または全部が同じ照会条件に完全に合致する取引をインデックスデータベースから検索するものであり、すなわち、検索された取引情報が少なくとも照会条件のうちの１つに合致し、ここで、検索された取引情報が取引ノートインデックス情報条件の指定値およびその順序を含む場合にのみ、当該取引情報が照会条件の取引ノートインデックス情報条件に合致すると考えられる。

前記取引ノートインデックス情報に基づく順次正確な照会は、検証ノードが、取引ノートインデックスフィールドが照会条件で指定された取引ノートインデックスフィールドに完全に合致する取引をインデックスデータベースから検索するものであり、照会条件で指定された取引ノートインデックス情報のデータタイプが配列である場合、インデックスデータベースから検索された取引に含まれる取引ノートインデックスフィールドが必ず配列であり、かつ配列の要素および順序が、照会条件で指定された取引ノートインデックスフィールドで指定された値および順序と完全に等しくなることが求められる。

前記取引ノートインデックス情報に基づく非順次正確な照会は、検証ノードが、取引ノートインデックスフィールドが照会条件で指定された取引ノートインデックス情報の全部を含む取引をインデックスデータベースから検索するものであり、このような検索モードでは、照会条件で指定された取引ノートインデックス情報のデータタイプが配列でなければならず、インデックスデータベースから検索された取引に含まれる取引ノートインデックスフィールドが必ず配列であり、かつ照会条件で指定された取引ノートインデックス情報配列のすべての値を含むことが求められ、配列の値の順序は問われない。

前記取引ノートインデックス情報に基づく非順次一致照会は、検証ノードが、取引ノートインデックスフィールドが照会条件で指定された取引ノートインデックス情報の一部または全部を含む取引をインデックスデータベースから検索するものであり、このような検索モードでは、照会条件で指定された取引ノートインデックス情報のデータタイプが配列でなければならず、インデックスデータベースから検索された取引に含まれる取引ノートインデックスフィールドは、照会条件配列の任意の値を含むか、またはそれと等しい限り、配列でも非配列でもよい。検索された取引ノートインデックスフィールドが配列であり、かつ配列が複数の照会条件で指定された取引ノートインデックス情報配列で指定された複数の値を含む場合、配列内のこれらの値の順序が照会条件配列と一致するかどうかにかかわらず、照会条件に合致する取引であると考えられる。

データ量の飛躍的な増加に伴い、インデックスデータベースの検索効率にも影響が出てきて、データ検索効率をさらに高めるために、照会条件の使用率が高く、かつ照会効率が低い場合、インデックスデータベースの１層目インデックスに含まれるブロック番号、取引参加者、取引生成時間、取引ノートインデックス情報などのフィールドのいずれかに対してインデックス、すなわち２層目インデックスを作成することで、インデックスデータベースの照会効率を向上させる。検証ノードが２層目インデックスを作成した場合、ステップＳ３で１層目インデックスデータをインデックスデータベースに永続化する際に、インデックスデータベースの２層目インデックスを自動的に更新する。

前記２層目インデックスとは、インデックスデータベース内の１層目インデックスに含まれる特定のフィールドに対して作成したネイティブデータベースインデックスを意味し、その目的はインデックスデータベース内のデータ照会効率を高めることである。ブロックチェーンネットワークでは複数の分散型アプリケーションが実行されており、ブロックチェーンノード照会条件の使用率は、ブロックチェーン上の異なるアプリケーションシナリオに依存することが多く、異なるアプリケーションシナリオで生成される取引構造はすべて同様である。ブロックチェーン上で複数の分散型アプリケーション（ＤＡｐｐ）が実行されていることを想定し、ここで、ＤＡｐｐ Ａは、取引ノートインデックス情報に応じて完全な取引詳細を照会するニーズが高く、当該照会条件の使用率が高く、当該照会条件でのＤａｐｐ Ａの照会効率を向上させるために、インデックスデータベース内の取引ノートインデックスフィールドに対して２層目インデックスを作成することは一般的である。しかし、他のＤＡｐｐの場合、当該照会条件の使用率があまり高くないが、これらのＤＡｐｐに関連する取引も、対応する２層目インデックスデータを生成することで、ノード格納スペースを浪費している。

したがって、前記２層目インデックスは、全インデックスと部分インデックスに分ける必要がある。前記全インデックスとは、インデックスデータベース内のすべての１層目インデックスに含まれる特定のフィールドに対してネイティブデータベースインデックスを作成することを意味する。前記部分インデックスとは、インデックスデータベース内の一部の１層目インデックスに含まれる特定のフィールドに対してネイティブデータベースインデックスをフィルタ式によって作成し、すなわち、２層目インデックスを作成する際に、どの１層目インデックスの特定のフィールドに対して２層目インデックスを作成するか、どの１層目インデックスの特定のフィールドに対して２層目インデックスを作成しないかを指定するためにフィルタ式を追加することである。部分インデックスは、格納圧力を軽減し、２層目インデックスの作成や２層目インデックスの更新に伴う性能の低下を抑えることができる。ブロックチェーンの取引構造では、口座アドレスとして、内部口座アドレスと外部口座アドレスがあり、内部口座アドレスは通常の振込のための口座アドレス、外部口座アドレスは契約アドレスを指し、取引構造における取引受信者は、内部口座アドレスまたは外部口座アドレスのいずれかである。したがって、各ＤＡｐｐのために外部口座アドレスを初期化し、その後取引受信者アドレスによって異なるＤＡｐｐを区別することができる。さらに、引き続いて前述の例で説明する。ＤＡｐｐ Ａに対して部分インデックスを作成することで、それが取引ノートインデックス情報に基づいて完全な取引詳細を照会する照会効率を高め、かつ当該部分インデックスのフィルタ式を指定することができ、取引受信者アドレスがＤＡｐｐ Ａアドレスである。このやり方によって、ノードは、取引受信者アドレスがＤＡｐｐ Ａアドレスである取引に対してのみ２層目インデックスを作成し、それ以外の取引に対して２層目インデックスを作成しないようになる。

具体的には、読者がブロックチェーンデータのインデックス方法の有益な効果をさらに理解しやすいために、以下は例を挙げて、ブロックチェーンデータのインデックス方法を詳細に説明する。

例示的に、ブロックチェーンに基づく銀行間振込サービスシステムであって、全体的なシステムアーキテクチャは図４に示すとおりであり、銀行ＡとＢは、それぞれ２つのブロックチェーン検証ノードが配備され、かつそれぞれのサービスシステムを有する。

銀行Ａのユーザーから銀行Ｂのユーザーへの振込を想定した場合、銀行間振込流れとして、振込者が振込依頼を開始し、次に銀行Ａと銀行Ｂが当該依頼に対して、ユーザー口座が正当であるか否か、口座が凍結されているか否か、残高が十分であるか否かを検証するという承認を行い、承認が得られた後に振込を行う。これにより、振込流れは、複数のステップで構成されており、各ステップはそれぞれ、振込流れの状態を記録するためのブロックチェーン取引に対応している。サービスシステムは、ユーザーの銀行間振込が成功したか否かを知るために、振込流れの状態を照会する必要がある。このようなビジネスでは、各振込を唯一に識別するための振込流れＩＤを必要とし、かつ振込流れＩＤを照会条件として、当該振込流れに関連するブロックチェーン取引を検証ノードから照会して取得することができる。したがって、振込流れＩＤを取引ノートインデックスフィールドに定義し、その後、取引ノートインデックス情報の照会条件および取引ノートインデックスに基づく順次正確な照会検索モードで構成される照会要求により、検証ノードから必要なブロックチェーン取引データを照会して取得する必要がある。

例示的に、ブロックチェーンに基づく音楽著作権情報追跡システムであって、本出願が提供する技術により、音楽著作権情報の開放性と透明性、侵害のトレーサビリティーを容易に実現する。例えば、曲の所有者が、作詞者、作曲者、歌手、著作権所有者などを含む曲の著作権情報をブロックチェーン上に公開した場合、曲の利用者が商業的利益のためにその曲を利用し、かつ著作権の所有者に属さなければ、当該利用者が権利を侵害していると考えられる。曲の著作権が変更されるたびに、最新の著作権情報を記録するためのブロックチェーン取引が対応して生成される。このようなビジネスでは、曲の著作権情報が取引ノートフィールドに定義され、曲のオーディオファイルハッシュが取引ノートインデックスフィールドに定義され、その後、取引ノートインデックス情報を含む照会条件と取引ノートインデックスに基づく順次正確な照会検索モードで構成される照会要求により、条件に合致するブロックチェーン取引データを検証ノードから照会して取得し、さらに取引ノートフィールドに定義された詳細な曲著作権情報を得る。

例示的に、３つの検索モード、すなわち、取引ノートインデックス情報に基づく順次正確な照会、取引ノートインデックス情報に基づく非順次正確な照会、および取引ノートインデックス情報に基づく非順次一致照会の例を以下に示すが、それによって、このような検索モードへの読者の理解を容易にし、さらにブロックチェーンに基づく望ましいサービスシステムを開発することに役立つ。

取引ノートフィールドの名称が「ＥＸＴＲＡ」で、取引ノートインデックスフィールドの名称が「ＥＸＴＲＡ＿ＩＤ」であると想定し、さらに、現在、ブロックチェーン上には、ＥＸＴＲＡ＿ＩＤがそれぞれ［１２３， ”ａｂｃ”］、［”ａｂｃ”， １２３］、［１２３， ”ｅｆｇ”， ”ａｂｃ”］、［１２３］、［”ａｂｃ”］、１２３、”ａｂｃ」である７つの取引があると想定する。

検索モードが、取引ノートインデックス情報に基づく順次正確な照会である場合には、
照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： ［１２３］ ｝であれば、照会条件に合致するＥＸＴＲＡ＿ＩＤは［１２３］の１つしか存在しない。

照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： ”ａｂｃ” ｝であれば、照会条件に合致するＥＸＴＲＡ＿ＩＤは”ａｂｃ”の１つしか存在しない。

照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： ［１２３， ”ａｂｃ”］ ｝であれば、照会条件に合致するＥＸＴＲＡ＿ＩＤは［１２３， ”ａｂｃ”］の１つしか存在しない。

検索モードが、取引ノートインデックス情報に基づく非順次正確な照会である場合には、
照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： １２３ ｝ または ｛ ”ＥＸＴＲＡ＿ＩＤ”： ”ａｂｃ” ｝であれば、エラーを返す。その理由として、この検索モードでは、照会条件が配列タイプである必要がある。

照会条件が ｛ ”ＥＸＴＲＡ＿ＩＤ”： ［１２３］ ｝であれば、照会条件に合致するＥＸＴＲＡ＿ＩＤは、［１２３， ”ａｂｃ”］、［”ａｂｃ”， １２３］、［１２３， ”ｅｆｇ”， ”ａｂｃ”］、［１２３］の４つがある。

照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： ［１２３， ”ａｂｃ”］ ｝であれば、照会条件に合致するＥＸＴＲＡ＿ＩＤは、［１２３， ”ａｂｃ”］、［”ａｂｃ”， １２３］、［１２３， ”ｅｆｇ”， ”ａｂｃ”］の３つがある。

検索モードが、取引ノートインデックス情報に基づく非順次一致照会である場合には、
照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： １２３ ｝ または ｛ ”ＥＸＴＲＡ＿ＩＤ”： ”ａｂｃ” ｝であれば、エラーを返す。その理由として、この検索モードでは、照会条件が配列タイプである必要がある。

照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： ［１２３］ ｝であれば、照会条件に合致するＥＸＴＲＡ＿ＩＤは、［１２３， ”ａｂｃ”］、［”ａｂｃ”， １２３］、［１２３， ”ｅｆｇ”， ”ａｂｃ”］、［１２３］、１２３の５つがある。

照会条件が｛ ”ＥＸＴＲＡ＿ＩＤ”： ［１２３， ”ａｂｃ”］ ｝であれば、すべてのＥＸＴＲＡ＿ＩＤ、すなわち、［１２３， ”ａｂｃ”］、［”ａｂｃ”， １２３］、［１２３， ”ｅｆｇ”， ”ａｂｃ”］、［１２３］、［”ａｂｃ”］、１２３、”ａｂｃ”が照会条件に合致する。

［実施例２］
本出願の実施例はさらに、ブロックチェーンデータを格納する方法を提供し、格納方法は検証ノードに応用され、当該格納方法は、以下のステップＳ１０１、ステップＳ１０２、ステップＳ１０３、ステップＳ１０４、ステップＳ１０５、ステップＳ１０６を含む。

ステップＳ１０１、ブロックチェーン取引を取得する。

ここで、ブロックチェーン取引は、取引送信者、取引受信者、取引生成時間、取引ノートおよび取引ノートインデックスを含み、当該ブロックチェーン取引は、ブロックチェーンクライアントによって生成され、かつ検証ノードに送信され得る。

選択的に、取引ノートインデックスのデータタイプは、数値、文字列または配列であり、配列は、数値、文字列のうちの少なくとも１つで構成され、配列の要素は順序付けられている。

ここで、配列の要素は３０個以下であり、文字列は、１０２４ビット以下である。

選択的に、取引ノートは、ブロックチェーン取引を送信するブロックチェーンクライアントによってカスタマイズされた任意の取引関連データであり、取引ノートインデックスは、ブロックチェーン取引を送信するブロックチェーンクライアントによってカスタマイズされた任意の取引関連インデックスである。

ステップＳ１０２、ブロックチェーン取引に応じて、コンセンサス生成ブロックがブロックを生成した後にブロックを実行する。

ここで、検証ノードがブロックチェーン取引を受信すると、自身のコンセンサス生成ブロックがブロックを生成し、かつ当該ブロックを実行する。

ステップＳ１０３、ブロックのブロック番号を取得し、かつブロックに含まれる各取引の取引キー情報を抽出する。

ここで、ブロックに含まれる各取引の取引キー情報に応じてキー情報リストを生成し、キー情報リストに含まれる各取引の取引キー情報は、取引送信者、取引受信者、取引生成時間、取引ノートインデックス、ブロックにおける取引の位置を含む。

ステップＳ１０４、取引キー情報およびブロック番号に応じて、１層目インデックスデータを構築する。

ここで、１層目インデックスデータは、ブロックを単位とし、１単位はブロック番号および取引キー情報リスト（すなわち、各取引の取引キー情報）を含む。

選択的に、取引キー情報およびブロック番号に応じて、１層目インデックスデータを構築するステップの後、さらに、
１層目インデックスデータに含まれる目標フィールドに対して、２層目インデックスを作成し、新しい取引で構築された１層目インデックスデータをインデックスデータベースに永続化する際に、２層目インデックスを自動的に更新することを含み、目標フィールドが１層目インデックスデータに含まれる特定のフィールドである。

ここで、２層目インデックスとは、インデックスデータベース内の１層目インデックスに含まれる特定のフィールドに対して作成したネイティブデータベースインデックスを意味し、その目的はインデックスデータベース内のデータ照会効率を高めることである。ブロックチェーンネットワークでは複数の分散型アプリケーションが実行されており、ブロックチェーンノード照会条件の使用率は、ブロックチェーン上の異なるアプリケーションシナリオに依存することが多く、異なるアプリケーションシナリオで生成される取引構造はすべて同様である。ブロックチェーン上で複数の分散型アプリケーション（ＤＡｐｐ）が実行されていることを想定し、ここで、ＤＡｐｐ Ａは、取引ノートインデックス情報に応じて完全な取引詳細を照会するニーズが高く、当該照会条件の使用率が高く、当該照会条件でのＤａｐｐ Ａの照会効率を向上させるために、インデックスデータベース内の取引ノートインデックスフィールドに対して２層目インデックスを作成することは一般的である。しかし、他のＤＡｐｐの場合、当該照会条件の使用率があまり高くないが、これらのＤＡｐｐに関連する取引も、対応する２層目インデックスデータを生成することで、ノード格納スペースを浪費している。

選択的に、２層目インデックスは、全インデックスまたは部分インデックスであり、全インデックスとは、インデックスデータベースにおける各１層目インデックスデータの特定のフィールドに対してネイティブデータベースインデックスを作成することを意味し、部分インデックスとは、１層目インデックスデータの特定のフィールドに対して、インデックスデータベースにおける１層目インデックスデータの一部を選択してその特定のフィールドのネイティブデータベースインデックスを作成し、つまり、部分インデックスを作成する際に、どの１層目インデックスデータに対して２層目インデックスを作成し、どの１層目インデックスデータに対して２層目インデックスを作成しないかを指定するためのフィルタ式を追加することを意味する。

ここで、部分インデックスは、格納圧力を軽減し、２層目インデックスの作成や２層目インデックスの更新に伴う性能の低下を抑えることができる。ブロックチェーンの取引構造では、口座アドレスとして、内部口座アドレスと外部口座アドレスがあり、内部口座アドレスは通常の振込のための口座アドレス、外部口座アドレスは契約アドレスを指し、取引構造における取引受信者は、内部口座アドレスまたは外部口座アドレスのいずれかである。したがって、各ＤＡｐｐのために外部口座アドレスを初期化し、その後取引受信者アドレスによって異なるＤＡｐｐを区別することができる。さらに、引き続いて前述の例で説明する。ＤＡｐｐ Ａに対して部分インデックスを作成することで、それが取引ノートインデックス情報に基づいて完全な取引詳細を照会する照会効率を高め、かつ当該部分インデックスのフィルタ式を指定することができ、取引受信者アドレスがＤＡｐｐ Ａアドレスである。このやり方によって、ノードは、取引受信者アドレスがＤＡｐｐ Ａアドレスである取引に対してのみ２層目インデックスを作成し、それ以外の取引に対して２層目インデックスを作成しないようになる。

ステップＳ１０５、１層目インデックスデータをインデックスデータベースに永続化する。

ここで、１層目インデックスデータおよび対応するブロックが、同じ検証ノードの異なるデータベースに格納される。１層目インデックスデータは、インデックスデータベースに格納され、インデックスデータベースは、ＳＱＬ様照会をサポートする非リレーショナルデータベース、例えばＭｏｎｇｏＤＢである。１層目インデックスデータは、取引キー情報だけであり、インデックスデータベースに格納されるが、取引の完全な詳細情報および取引ノート情報はブロックファイルに格納されることで、インデックスデータベースの過剰な冗長格納が効果的に回避される。

ステップＳ１０６、ブロックをブロックファイルに永続化する。

ここで、ブロックは、Ｋｅｙ－Ｖａｌｕｅ型照会をサポートするブロックファイルに格納され、ここで、Ｋｅｙはブロック番号であり、Ｖａｌｕｅはブロック詳細であり、ブロックファイルは、ブロック番号に基づいてブロック詳細を得て、さらにブロック番号およびブロックにおける取引の位置に基づいて取引詳細を得ることのみをサポートしている。

インデックスデータベースとブロックファイルのデータ挿入は、トランザクションの原子性を有し、トランザクションの原子性とは、ノードがブロックを１つ生成するたびにデータ挿入トランザクションを生成することを意味し、複数のデータベースへの挿入は、すべてのデータベースへの新規データの挿入を成功させるか、新規データを挿入しないか、トランザクションの原子性を確保する必要がある。ブロックファイルに対するブロックの書き込みが成功し、インデックスデータベースへのデータ挿入が失敗した場合、ブロックファイルをロールバックする。インデックスデータベースに対するインデックスデータの挿入が成功し、ブロックファイルへの書き込みが失敗した場合、インデックスデータベースをロールバックする。したがって、ノードで新しいブロックが生成および格納されると、対応するインデックスデータが生成され、インデックスデータベースに格納されると考えられる。

選択的に、当該格納方法は、さらに、
ブロックチェーンクライアントが送信した照会要求を取得することと、
照会要求の検索モードに応じて、インデックスデータベースから、照会要求の照会条件に合致する取引キー情報に対応するブロック番号およびブロックにおける取引の位置を取得することと、
ブロック番号および位置に応じて、ブロックファイルに照会して完全な取引を取得することと、を含む。

ここで、照会要求は、照会条件および検索モードを含み、照会条件は、取引送信者、取引受信者、取引生成時間、取引ノートインデックス情報条件のいずれか１つ以上で構成され、ここで、取引ノートインデックス情報が配列である場合、その中の数値または文字列は対応する順序を有する。

選択的に、照会条件が取引ノートインデックスのみを含み、かつ指定された配列である場合、検索モードは、取引ノートインデックスに基づく順次正確な照会、取引ノートインデックスに基づく非順次正確な照会、または取引ノートインデックスに基づく非順次一致照会から選択され、照会条件がそれ以外の場合、検索モードは、複数条件ＡＮＤ照会または複数条件ＯＲ照会から選択される。

選択的に、複数条件ＡＮＤ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件のすべての項目に合致するものであり、複数条件ＯＲ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件の少なくとも１項目に合致するものであり、ここで、特定の取引の取引キー情報に含まれる取引送信者、取引受信者または取引生成時間が、照会条件で指定された取引送信者、取引受信者または取引生成時間と同様である場合、当該取引の取引キー情報が照会条件の対応する１項目に合致することを示し、照会条件で指定された取引ノートインデックスが配列である場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示し、照会条件で指定された取引ノートインデックスが配列ではない場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの数値または文字列と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示す。

ここで、複数条件ＡＮＤ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件のすべての項目に合致するものであり、すなわち、複数条件ＡＮＤ照会は、検証ノードが、取引情報が照会条件に完全に合致する取引をインデックスデータベースから検索するものであり、照会条件が取引送信者、取引受信者または取引生成時間を含む場合、それに対応して、検索された取引情報に含まれる取引送信者フィールド、取引受信者フィールド、および取引生成時間フィールドの値が、照会条件で指定された取引送信者、取引受信者および取引生成時間の値と等しくなり、照会条件が取引ノートインデックス情報条件を含む場合、それに対応して、検索された取引情報に含まれる取引ノートインデックスフィールドが、照会条件で指定された取引ノートインデックス値と等しくなり、それに対応して、照会条件で指定された取引ノートインデックス値が配列である場合、検索された取引情報の取引ノートインデックスフィールド値も配列であり、かつ配列の要素値および要素順序が照会条件で指定された配列と完全に一致する。

複数条件ＯＲ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件の少なくとも１項目に合致するものであり、すなわち、複数条件ＯＲ照会は、検証ノードが、取引情報の一部または全部が同じ照会条件に完全に合致する取引をインデックスデータベースから検索するものであり、検索された取引情報が少なくとも照会条件のうちの１つに合致し、ここで、検索された取引情報が取引ノートインデックス情報条件の指定値およびその順序を含む場合にのみ、当該取引情報が照会条件の取引ノートインデックス情報条件に合致すると考えられる。

選択的に、取引ノートインデックスに基づく順次正確な照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であるということであり、取引ノートインデックスに基づく非順次正確な照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素と同様であるということであり、取引ノートインデックスに基づく非順次一致照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素の少なくとも１つを含むということである。

ここで、取引ノートインデックスに基づく順次正確な照会は、検証ノードが、取引ノートインデックスフィールドが照会条件で指定された取引ノートインデックスフィールドに完全に合致する取引をインデックスデータベースから検索するものであり、照会条件で指定された取引ノートインデックス情報のデータタイプが配列である場合、インデックスデータベースから検索された取引に含まれる取引ノートインデックスフィールドが必ず配列であり、かつ配列の要素および順序が、照会条件で指定された取引ノートインデックスフィールドで指定された値および順序と完全に等しくなることが求められる。

取引ノートインデックスに基づく非順次正確な照会は、検証ノードが、取引ノートインデックスフィールドが照会条件で指定された取引ノートインデックス情報の全部を含む取引をインデックスデータベースから検索するものであり、このような検索モードでは、照会条件で指定された取引ノートインデックス情報のデータタイプが配列でなければならず、インデックスデータベースから検索された取引に含まれる取引ノートインデックスフィールドが必ず配列であり、かつ照会条件で指定された取引ノートインデックス情報配列のすべての値を含むことが求められ、配列の値の順序は問われない。

取引ノートインデックスに基づく非順次一致照会は、検証ノードが、取引ノートインデックスフィールドが照会条件で指定された取引ノートインデックス情報の一部または全部を含む取引をインデックスデータベースから検索するものであり、このような検索モードでは、照会条件で指定された取引ノートインデックス情報のデータタイプが配列でなければならず、インデックスデータベースから検索された取引に含まれる取引ノートインデックスフィールドは、照会条件配列の任意の値を含むか、またはそれと等しい限り、配列でも非配列でもよい。検索された取引ノートインデックスフィールドが配列であり、かつ配列が複数の照会条件で指定された取引ノートインデックス情報配列で指定された複数の値を含む場合、配列内のこれらの値の順序が照会条件配列と一致するかどうかにかかわらず、照会条件に合致する取引であると考えられる。

上述した実施例は、本出願の技術的解決手段を説明するためのものに過ぎず、これらを限定するためのものではない。前記の実施例を参照しながら本出願を詳細に説明したが、当業者であれば、前記の各実施例に記載された技術的解決手段を修正したり、それらの技術的特徴の一部を等価的に置き換えたりすることができることを理解すべきである。これらの修正や置き換えは、対応する技術的解決手段の本質を本出願の各実施例の技術的解決手段の要旨および範囲から逸脱させることなく、いずれも本出願の保護の範囲に含まれるものとする。

Claims (20)

1. ブロックチェーンクライアントが、ブロックチェーン取引を生成して検証ノードに送信するステップ（１）であって、前記ブロックチェーン取引は、取引送信者、取引受信者、取引生成時間、取引ノートおよび取引ノートインデックスを含み、前記取引ノートインデックスのデータタイプは、数値、文字列または配列であり、前記配列は、数値、文字列のうちの少なくとも１つで構成され、配列の要素は順序付けられている、ステップ（１）と、
   検証ノードがステップ（１）で送信された取引を受信すると、コンセンサス生成ブロックがブロックを生成した後にブロックを実行し、次にブロックに含まれる各取引の取引キー情報を抽出して取引キー情報リストを構成し、１層目インデックスデータを構築するステップ（２）であって、前記１層目インデックスデータは、ブロック番号および取引キー情報リストを含み、前記取引キー情報は、取引送信者、取引受信者、取引生成時間、取引ノートインデックス、およびブロックにおける取引の位置を含む、ステップ（２）と、
   検証ノードは、ステップ（２）で生成されたブロックをブロックファイルに永続化し、ステップ（２）で構築された１層目インデックスデータをインデックスデータベースに永続化するステップ（３）と、
   クライアントが、照会条件と検索モードを含む照会要求を検証ノードに送信するステップ（４）であって、前記照会条件は、指定された取引送信者、取引受信者、取引生成時間、取引ノートインデックスのうちの１つ以上で構成され、前記検索モードは、複数条件ＡＮＤ照会、複数条件ＯＲ照会、取引ノートインデックスに基づく順次正確な照会、取引ノートインデックスに基づく非順次正確な照会、および取引ノートインデックスに基づく非順次一致照会を含む、ステップ（４）と、
   検証ノードは、ステップ（４）でクライアントが送信した照会要求の検索モードに応じて、ステップ（３）で得られたインデックスデータベースから、照会条件に合致する取引キー情報に対応するブロック番号およびブロックにおける取引の位置を取得し、ステップ（３）で得られたブロックファイルに照会して完全な取引を取得し、クライアントに返信するステップ（５）と、を含む、ことを特徴とするブロックチェーンデータをインデックスする方法。
2. 照会条件が取引ノートインデックスのみを含み、かつ指定された配列である場合、前記検索モードは、取引ノートインデックスに基づく順次正確な照会、取引ノートインデックスに基づく非順次正確な照会または取引ノートインデックスに基づく非順次一致照会から選択され、照会条件がそれ以外の場合、前記検索モードは、複数条件ＡＮＤ照会、または複数条件ＯＲ照会から選択される、ことを特徴とする請求項１に記載のブロックチェーンデータをインデックスする方法。
3. 前記複数条件ＡＮＤ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件のすべての項目に合致するものであり、前記複数条件ＯＲ照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件の少なくとも１項目に合致するものであり、ここで、特定の取引の取引キー情報に含まれる取引送信者、取引受信者または取引生成時間が、照会条件で指定された取引送信者、取引受信者または取引生成時間と同様である場合、当該取引の取引キー情報が照会条件の対応する１項目に合致することを示し、照会条件で指定された取引ノートインデックスが配列である場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示し、照会条件で指定された取引ノートインデックスが配列ではない場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの数値または文字列と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示す、ことを特徴とする請求項２に記載のブロックチェーンデータをインデックスする方法。
4. 前記取引ノートインデックスに基づく順次正確な照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であるということであり、前記取引ノートインデックスに基づく非順次正確な照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素と同様であるということであり、前記取引ノートインデックスに基づく非順次一致照会は、検証ノードがインデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素の少なくとも１つを含むことを示す、ことを特徴とする請求項２に記載のブロックチェーンデータをインデックスする方法。
5. ステップ（３）で得られたインデックスデータベースにおける１層目インデックスデータに含まれる特定のフィールドに対して、ネイティブデータベースインデックスを２層目インデックスとして作成し、検証ノードが新規取引で構築された１層目インデックスデータをインデックスデータベースに永続化する際に、２層目インデックスを自動的に更新する、ことを特徴とする請求項１に記載のブロックチェーンデータをインデックスする方法。
6. 前記２層目インデックスは、全インデックスまたは部分インデックスであり、前記全インデックスとは、インデックスデータベースにおける各１層目インデックスデータの特定のフィールドに対してネイティブデータベースインデックスを作成することを意味し、前記部分インデックスとは、１層目インデックスデータの特定のフィールドに対して、インデックスデータベースにおける１層目インデックスデータの一部を選択してその特定のフィールドのネイティブデータベースインデックスを作成し、つまり、部分インデックスを作成する際に、どの１層目インデックスデータに対して２層目インデックスを作成し、どの１層目インデックスデータに対して２層目インデックスを作成しないかを指定するためのフィルタ式を追加することを意味する、ことを特徴とする請求項５に記載のブロックチェーンデータをインデックスする方法。
7. 前記取引ノートは、ブロックチェーンクライアントによってカスタマイズされた任意の取引関連データであり、前記取引ノートインデックスは、ブロックチェーンクライアントによってカスタマイズされた任意の取引関連インデックスである、ことを特徴とする請求項１に記載のブロックチェーンデータをインデックスする方法。
8. 前記配列の要素は、３０個以下である、ことを特徴とする請求項１に記載のブロックチェーンデータをインデックスする方法。
9. 前記文字列は、１０２４ビット以下である、ことを特徴とする請求項１に記載のブロックチェーンデータをインデックスする方法。
10. 前記ブロックファイルは、Ｋｅｙ－Ｖａｌｕｅ型照会をサポートし、前記インデックスデータベースは、ＳＱＬ様照会をサポートする非リレーショナルデータベースを使用する、ことを特徴とする請求項１に記載のブロックチェーンデータをインデックスする方法。
11. 前記格納方法が検証ノードに適用され、前記格納方法は、
    取引送信者、取引受信者、取引生成時間、取引ノートおよび取引ノートインデックスを含むブロックチェーン取引を取得することと、
    前記ブロックチェーン取引に応じて、コンセンサス生成ブロックがブロックを生成した後に前記ブロックを実行することと、
    前記ブロックのブロック番号を取得し、かつ前記ブロックにおける各取引の、取引送信者、取引受信者、取引生成時間、取引ノートインデックス、ブロックにおける取引の位置を含む取引キー情報を抽出することと、
    前記取引キー情報および前記ブロック番号に応じて、１層目インデックスデータを構築することと、
    前記１層目インデックスデータをインデックスデータベースに永続化することと、
    前記ブロックをブロックファイルに永続化することと、を含む、ことを特徴とするブロックチェーンデータを格納する方法。
12. 上述した前記取引キー情報および前記ブロック番号に応じて、１層目インデックスデータを構築するステップの後、さらに、
    前記１層目インデックスデータに含まれる目標フィールドに対して、２層目インデックスを作成し、新しい取引で構築された１層目インデックスデータをインデックスデータベースに永続化する際に、２層目インデックスを自動的に更新することを含み、前期目標フィールドが前期１層目インデックスデータに含まれる特定のフィールドである、ことを特徴とする請求項１１に記載の格納方法。
13. 前記２層目インデックスは、全インデックスまたは部分インデックスであり、
    前記全インデックスとは、前記インデックスデータベースにおける各１層目インデックスデータの特定のフィールドに対してネイティブデータベースインデックスを作成することを意味し、
    前記部分インデックスとは、１層目インデックスデータの特定のフィールドに対して、前記インデックスデータベースにおける１層目インデックスデータの一部を選択してその特定のフィールドのネイティブデータベースインデックスを作成し、つまり、部分インデックスを作成する際に、どの１層目インデックスデータに対して２層目インデックスを作成し、どの１層目インデックスデータに対して２層目インデックスを作成しないかを指定するためのフィルタ式を追加することを意味する、ことを特徴とする請求項１２に記載の格納方法。
14. 前記格納方法はさらに、
    ブロックチェーンクライアントが送信した照会要求を取得することと、
    前記照会要求の検索モードに応じて、前記インデックスデータベースから、前記照会要求の照会条件に合致する取引キー情報に対応するブロック番号およびブロックにおける取引の位置を取得することと、
    前記ブロック番号および前記位置に応じて、前記ブロックファイルに照会して完全な取引を取得することとを含む、ことを特徴とする請求項１１に記載の格納方法。
15. 前記照会条件が取引ノートインデックスのみを含み、かつ指定された配列である場合、前記検索モードは、前記取引ノートインデックスに基づく順次正確な照会、前記取引ノートインデックスに基づく非順次正確な照会または前記取引ノートインデックスに基づく非順次一致照会から選択され、照会条件がそれ以外の場合、前記検索モードは、複数条件ＡＮＤ照会、または複数条件ＯＲ照会から選択される、ことを特徴とする請求項１４に記載の格納方法。
16. 前記複数条件ＡＮＤ照会は、検証ノードが前記インデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件のすべての項目に合致するものであり、
    前記複数条件ＯＲ照会は、検証ノードが前記インデックスデータベースから検索して得られた特定の取引の取引キー情報が照会条件の少なくとも１項目に合致するものであり、
    ここで、特定の取引の取引キー情報に含まれる取引送信者、取引受信者または取引生成時間が、照会条件で指定された取引送信者、取引受信者または取引生成時間と同様である場合、当該取引の取引キー情報が照会条件の対応する一項目に合致することを示し、
    照会条件で指定された取引ノートインデックスが配列である場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示し、
    照会条件で指定された取引ノートインデックスが配列ではない場合、特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの数値または文字列と同様であれば、当該取引の取引キー情報が照会条件中の当該項目に合致することを示す、ことを特徴とする請求項１５に記載の格納方法。
17. 上述した前記取引ノートインデックスに基づく順次正確な照会は、検証ノードが前記インデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素およびその順序と同様であるということであり、
    上述した取引ノートインデックスに基づく非順次正確な照会は、検証ノードが前記インデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素と同様であるということであり、
    上述した取引ノートインデックスに基づく非順次一致照会は、検証ノードが前記インデックスデータベースから検索して得られた特定の取引の取引キー情報に含まれる取引ノートインデックスが、照会条件で指定された取引ノートインデックスの要素の少なくとも１つを含むということである、ことを特徴とする請求項１５に記載の格納方法。
18. 前記取引ノートインデックスのデータタイプは、数値、文字列または配列であり、前記配列は、数値、文字列のうちの少なくとも１つで構成され、配列の要素は順序付けられている、ことを特徴とする請求項１１に記載の格納方法。
19. 前記取引ノートは、前記ブロックチェーン取引を送信するブロックチェーンクライアントによってカスタマイズされた任意の取引関連データであり、前記取引ノートインデックスは、前記ブロックチェーン取引を送信するブロックチェーンクライアントによってカスタマイズされた任意の取引関連インデックスである、ことを特徴とする請求項１８に記載の格納方法。
20. 前記ブロックファイルは、Ｋｅｙ－Ｖａｌｕｅ型照会をサポートし、前記インデックスデータベースは、ＳＱＬ様照会をサポートする非リレーショナルデータベースを使用する、ことを特徴とする請求項１１に記載の格納方法。

Images