JP2020508503A - ブロックチェーンベースのデータ記憶および照会方法およびデバイス - Google Patents

Abstract

本出願では、ブロックチェーンベースのデータ記憶および照会方法が開示され、この方法は、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードが、サービス要求内から各データカテゴリおよび各データカテゴリに対応するサービスデータを構文解析し、データカテゴリとサービスデータとの対応関係に従ってブロックチェーンノードに対応するデータベースに、構文解析したサービスデータを記憶することができることを含む。本発明では、サービスデータを構文解析することによって、サービスデータは、データカテゴリとサービスデータとの対応関係に従ってブロックチェーンノードに対応するデータベースに記憶することができ、したがって、サービスデータを照会するとき、ユーザは、データベースで記述された対応関係に基づいて照会を行うことができ、これにより、既存のブロックチェーンでのインデックスに基づく照会の問題を回避し、したがってブロックチェーンでのデータ照会の柔軟性を高め、データ照会の効率を効果的に上げることができる。

Description

本出願は、コンピュータ技術の分野に関し、詳細には、ブロックチェーンベースのデータ記憶および照会方法およびデバイスに関する。

コンピュータ技術が絶えず発達するにつれて、新しい分散データ記憶技術であるブロックチェーン技術は、ますます普及している。改ざん耐性がブロックチェーン技術(分散型台帳技術と呼ばれることもある)の特徴であるので、ブロックチェーンに記憶されたデータは信頼できるものであるからである。

ブロックチェーンのデータ記憶の原理は、以下のように理解することができる。ユーザが、Ethereumクライアント(すなわち、ブロックチェーン技術をサポートするクライアント、ブロックチェーンクライアントと呼ばれることもある)を使用することによってサービス要求を開始する。Ethereumクライアントは、サービス要求を合意ネットワークに送ることができる。合意ネットワークの各ブロックチェーンノードが、サービス要求に関して合意手続きを行う。合意ネットワークの各ブロックチェーンノードは、サービス要求に関して合意に達した後、各ブロックチェーンノードに対応するブロックチェーンにサービス要求中のデータダイジェストを記憶する。加えて、Ethereumクライアントは、Ethereumクライアントに対応する記憶媒体にサービス要求中のサービスデータを、スマートコントラクトで指定された所定のデータ記憶フォーマットに基づいて記憶することができる。

その後、記憶媒体に記憶されたデータの照会に役立つように、通常、インデックスが所定の方法で作成され、これによりユーザは、インデックスを使用することによって、記憶媒体に記憶されたサービスデータに照会動作を行うことができる。

しかしながら、実際には、サービスデータを照会するために使用される照会条件が、作成されたインデックスとは異なる(言い換えれば、照会条件がスマートコントラクトで指定されたインデックスに一致しない)と、データ照会効率が比較的低く、または照会が失敗する。

本出願の一実装形態は、ブロックチェーンに記憶されたデータが照会されるとき、照会効率が低い、または照会が失敗するなどの、既存の技術の問題を緩和するために、データ記憶方法を提供する。

本出願の一実装形態は、ブロックチェーンノードによってサービス要求を受信するステップと、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析するステップと、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶するステップとを含む、データ記憶方法を提供する。

本出願の一実装形態は、ブロックチェーンに記憶されたデータが照会されるとき、照会効率が低い、または照会が失敗するなどの、既存の技術の問題を緩和するために、データ記憶デバイスを提供する。

本出願の一実装形態は、サービス要求を受信するように構成された受信モジュールと、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析するように構成されたデータ構文解析モジュールと、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶するように構成された記憶モジュールとを含む、データ記憶デバイスを提供する。

本出願の一実装形態は、ブロックチェーンに記憶されたデータが照会されるとき、照会効率が低い、または照会が失敗するなどの、既存の技術の問題を緩和するために、データ照会方法を提供する。

本出願の一実装形態は、ブロックチェーンノードによって、サービスデータ照会要求を受信するステップと、サービスデータ照会要求に基づいて、照会されるサービスデータに対応するデータタイプを決定するステップと、ブロックチェーンノードに対応するデータベースからデータタイプに一致するサービスデータを照会するステップであって、データベースがデータタイプとサービスデータとのマッピング関係を含む、照会するステップとを含む、データ照会方法を提供する。

本出願の一実装形態は、ブロックチェーンに記憶されたデータが照会されるとき、照会効率が低い、または照会が失敗するなどの、既存の技術の問題を緩和するために、データ照会方法を提供する。

本出願の一実装形態は、サービスデータ照会要求を受信するように構成された要求受信モジュールと、サービスデータ照会要求に基づいて、照会されるサービスデータに対応するデータタイプを決定するように構成されたタイプ決定モジュールと、デバイスに対応するデータベースからデータタイプに一致するサービスデータを照会するように構成されたデータ照会モジュールであって、データベースがデータタイプとサービスデータとのマッピング関係を含む、データ照会モジュールとを含む、データ照会デバイスを提供する。

本出願の実装形態で使用される前述の技術的解決策の少なくとも1つは、以下の有益な効果を実現することができる。

本出願の実装形態では、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析し、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。サービスデータは、構文解析により取得され、サービスデータは、ブロックチェーンノードに対応するデータベースに、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。したがって、ユーザは、データベースでそのようなマッピング関係に基づいてサービスデータを照会することができ、それによって、インデックスに基づいてブロックチェーンで照会を行う既存の技術の問題を緩和し、ブロックチェーンでのデータ照会の柔軟性および効率を効果的に上げる。

本明細書で説明する添付の図面は、本出願のさらなる理解を可能にし、本出願の一部を構成することを目的としている。本出願の例示的な実装形態およびそれの説明は、本出願を説明することを目的とし、本出願に制限を与えない。

本出願の一実装形態による、データ記憶プロセスを示す概略図である。 本出願の一実装形態による、データテーブルを示す概略図である。 本出願の一実装形態による、詳細なデータ記憶プロセスを示す図である。 本出願の一実装形態による、データ記憶デバイスを示す概略図である。 本出願の一実装形態による、データ照会デバイスを示す概略図である。

本出願の技術的解決策を当業者により良く理解してもらうために、以下に、本出願の実装形態の添付の図面を参照して、本出願の実装形態の技術的解決策を明確かつ包括的に説明する。説明する実装形態は、本出願の実装形態の全部ではなく一部にすぎないことは明らかである。創造的な取組みなしに、本出願の実装形態に基づいて当業者によって得られる他のすべての実装形態が、本出願の保護範囲内に含まれるものとする。

図1は、本出願の一実装形態による、データ記憶プロセスを示す概略図である。このプロセスは、以下のステップを含む。

S101.ブロックチェーンノードが、サービス要求を受信する。

実際には、サービス処理プロセスで、ユーザがブロックチェーンノードにサービス要求を送ることができる。ブロックチェーンノードは、エンドユーザのデバイスまたはサーバであることがある。たとえば、ブロックチェーンノードがサーバであるとき、ユーザは、ユーザによって保有されるエンドユーザのデバイス上のサービス情報を記入することができる。ユーザがエンドユーザのデバイス上で指定された動作を行った後、エンドユーザのデバイスは、ユーザによって記入されたサービス情報をサービス要求の形式でサーバに送る。対応して、サーバは、サービス要求を受信することができる。

ブロックチェーンノードがエンドユーザのデバイスであるとき、ユーザは、エンドユーザのデバイス上のサービス情報を記入することができる。エンドユーザのデバイスは、ユーザが指定された動作を行う(たとえば、ユーザがタップ動作を行う)と決定すると、対応するサービス要求を生成することができる。これは、ユーザによって送られたサービス要求を受信することに相当する。

確かに、ブロックチェーンノードは、代替として、ブロックチェーンクライアント(ブロックチェーン技術に基づく関連サービスを処理することができるクライアントと呼ばれる、たとえばEthereumクライアント)であることがある。対応して、ブロックチェーン合意ネットワークを使用することによってサービス処理を行うと、ユーザは、エンドユーザのデバイスを使用することによってブロックチェーンクライアントを開始し、ブロックチェーンクライアントによって表示されるインターフェースにサービス情報を記入することができる。ブロックチェーンクライアントは、ユーザが指定された動作を行うことを検出するとき、ユーザによって記入されたサービス情報に基づいて対応するサービス要求を生成することができる。これは、ユーザによって送られたサービス要求を受信することに相当する。加えて、ブロックチェーンノードによって受信されたサービス要求は、代替として、別のブロックチェーンノードによってブロードキャストされ得る。

S102.データシーケンスを取得するために、所定のデータフォーマットに基づいてサービス要求を変換する。

ブロックチェーンノードは、対応するデータシーケンスを取得するために、サービス要求を受信した後、所定のデータフォーマットに基づいてサービス要求を変換することができる。

本出願の本実装形態では、所定のデータフォーマットは、限定はしないが、以下のフィールド、すなわち識別情報フィールド、およびサービスタイプフィールドを含む。

識別情報フィールドは、ユーザレベルのサービスデータ、たとえば、ユーザ公開キーまたはユーザ識別情報(ID)など、ユーザを一意に識別することができ、サービス要求に含まれる情報を区別するために使用され、これによりサービスデータを、ユーザディメンション(user dimension)で照会することができる。

サービスタイプフィールドは、ユーザの様々なサービスのサービスデータを区別するために使用され、これによりユーザはその後、サービスデータ照会プロセスにおいてサービスディメンションでサービスデータを照会することができる。

加えて、データフィールドが、所定のデータフォーマットで指定される。データフィールドは、各データタイプとサービス要求中の各サービスデータとのマッピング関係を示すために使用される。たとえば、サービス要求が次のデータフィールド:名前-Xiaoming、年齢-18、および体重-65kgを含むと仮定する。情報中、実際のサービスデータは、Xiaoming、18、および65kgであり、名前、年齢、および体重は、サービスデータのデータタイプである。言い換えれば、本出願の本実装形態では、データタイプはキーに相当し、サービスデータは値に相当し、データフィールドは、キー-値のデータマッピングセットである。

前述の所定のデータフォーマットに基づいて、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、識別情報、サービスタイプ、各データタイプに対応するサービスデータ、およびデータフィールドにある各データタイプなど、サービス要求に含まれるデータコンテンツを取得するためにサービス要求を、所定のデータフォーマットに基づいて構文解析することができる。ブロックチェーンノードは次いで、データシーケンスを取得するために、構文解析により取得されるデータを、特定の形式でシリアル化することができる。

たとえば、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、所定のデータフォーマットに基づいてサービス要求を構文解析することによって、以下のフィールド、すなわち、サービスタイプフィールド:商品(commodity)、識別情報フィールド:PublicKey、データフィールド:名前(name):傘(umbrella)、および原価(cost):46を取得すると仮定する。ブロックチェーンノードは、構文解析により取得されたこれらのフィールドを、特定の形式でシリアル化し、以下のデータシーケンスを取得する。
{"PublicKey.schema": "DEFAULT", "data": "name: umbrella, cost: 46"}.

本明細書の本実装形態では、ブロックチェーンノードは、その後のサービスデータ検証のためにサービス要求をブロックチェーンに書き込む必要があるので、サービス要求は、所定のデータフォーマットに基づいてデータシーケンスに変換される。実際には、ブロックチェーンノードは、通常、特定のデータフォーマットに基づいてブロックチェーンにサービス要求を書き込む必要がある。したがって、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、その後のプロセスでブロックチェーンにサービス要求を書き込むことをサポートするために、所定のデータフォーマットに基づいてサービス要求をデータフォーマット、すなわちデータシーケンスに変換する必要があり、さらに、サービスデータがブロックチェーンに記憶されたサービス要求に基づいて効果的に検証され得るように、データシーケンスの形式でブロックチェーンにサービス要求を書き込む。

本出願の本実装形態では、ブロックチェーンノードが、代替として、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析し、次いで、データシーケンスを取得するために、構文解析により取得される各データタイプに対応するサービスデータおよび各データタイプを、所定のデータフォーマットに基づいて変換することができることは注目に値する。代替として、構文解析により、各データタイプおよび各データタイプに対応するサービスデータを取得した後、ブロックチェーンノードはまず、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶し(言い換えれば、ステップS103を実行し)、次いで、データシーケンスを取得するために、サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを、所定のデータフォーマットに基づいて変換することができる。

言い換えれば、本出願の本実装形態では、データシーケンスを取得するために、所定のデータフォーマットに基づいてサービス要求を変換するステップはオプションである。

データシーケンスを取得するために所定のデータフォーマットに基づいてサービス要求を変換するステップS102に含まれる特定の実装形態プロセスは、必ずしも、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析し、次いで、データシーケンスを取得するために、構文解析により取得される各データタイプに対応するサービスデータおよび各データタイプを、所定のデータフォーマットに基づいて変換するプロセスであるとは限らない。データシーケンスは、代替として、サービス要求を構文解析することによって取得される各データタイプに対応するサービスデータおよび各データタイプ以外の、サービス要求中の別のフィールドを使用することによって生成することができる。データシーケンスを生成するために必要とされる特定のフィールドは、ブロックチェーンへのサービス要求の書込みをサポートするために実際に必要とされるデータフォーマットによって決まる。

S103.各データタイプおよび各データタイプに対応するサービスデータを取得するために、サービス要求を構文解析する。

本出願の本実装形態では、サービス要求を受信した後、ブロックチェーンノードは、まず、ブロードキャストにより合意ネットワークの他のブロックチェーンノードにサービス要求を送ることができ、これにより合意ネットワークの各ブロックチェーンノードが、サービス要求に関して合意手続きを行う。各ブロックチェーンノードは、合意ネットワークの各ブロックチェーンノードがサービス要求に関して合意に達したと決定した後、ブロックチェーンノードに対応するブロックチェーンにサービス要求を記憶することができる。

加えて、本出願の本実装形態では、サービス要求を受信した後、ブロックチェーンノードは、サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析し、その後のプロセスでブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。

本出願の本実装形態において言及するデータベースは、リレーショナルデータベースとすることができる。そのようなデータ記憶方法では、データを迅速に照会することができ、照会は照会条件によって影響を受けない。言い換えれば、たとえインデックスフィールドが変わっても、データベースに記憶されたサービスデータは、新しいインデックスフィールドに依然として適応することができ、ユーザによって照会されるサービスデータは、サービスデータを照会するために使用されるインデックスフィールドの変更によって影響を受けない。

本出願の本実装形態では、サービスデータ記憶中に、ブロックチェーンノードは、記憶されるサービスデータを、サービスタイプまたは識別情報に基づいて区別することができ、これにより異なるサービスタイプまたは識別情報に対応するサービスデータを、異なるデータベースに記憶することができる。したがって、ユーザは、その後のサービスデータ照会プロセスにおいてサービスタイプまたは識別情報ディメンションでサービスデータを正確に照会することができる。

これに基づいて、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析することに加えて、ブロックチェーンノードは、構文解析により、サービス要求に含まれるサービスデータに対応するサービスタイプおよび識別情報を取得し、次いで、データ記憶ステートメントを取得するために、構文解析により取得される各データタイプ、各データタイプに対応するサービスデータ、サービスタイプ、および識別情報を所定のステートメントフォーマットに基づいて変換し、その後のプロセスにおいてブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データ記憶ステートメントを実行することによって記憶することができる。

たとえば、ブロックチェーンノードは、サービス要求を構文解析することによって、記憶されるサービスデータはshoes#12xewおよび158であり、記憶されるサービスデータに対応するサービスタイプは商品であり、記憶されるサービスデータに対応する識別情報はPublicKey1であり、サービスデータshoes#12xewおよび158にそれぞれ対応するデータタイプは、名前および原価であると決定する。ブロックチェーンノードは、対応するデータ記憶ステートメントを取得するために、構文解析により取得されるサービスタイプ、識別情報、各データタイプに対応するサービスデータ、および各データタイプを、所定のステートメントフォーマットに基づいて変換することができる。例示的な形式は以下の通りである。

insert into "PublicKey1.schema: commodity" (name, cost) value ('shoes#12xew', '158').

ブロックチェーンノードは、データ記憶ステートメントを実行することによって、その後のプロセスでブロックチェーンノードに対応するデータベースにサービスデータを記憶することができる。

ブロックチェーンノードは、所定の構文解析プログラムを使用することによって、サービス要求を構文解析することができる。構文解析プログラムは、構文解析に使用されるデータフォーマット、および構文解析されるフィールドを指定する。ブロックチェーンノードは、構文解析プログラムを実行することによって、サービス要求を構文解析することができる。構文解析プログラムは、実際のニーズに基づいてブロックチェーンノードの運用および保守要員によってコンパイルされ得る。

サービスタイプおよび識別情報ディメンションでデータベースにサービスデータを記憶するのとは異なり、ブロックチェーンノードが単一のデータベースに対応する場合、データベースに異なるデータテーブルが設定できることは注目に値する。各サービスタイプおよび各識別情報が、1つのデータテーブルに対応することができる。したがって、ブロックチェーンノードは、サービスタイプおよび識別情報に基づいて、データベースのデータテーブルにサービスデータを記憶することができる。確かに、サービスタイプおよび識別情報に対応するサービスデータは、データテーブルの形式以外の形式のデータベースで区別され得る。本明細書では簡単のために詳細を省く。

本出願の本実装形態では、ブロックチェーンノードは、ステップS103を行った後にステップS102を行うことができ、ステップS102を行った後にステップS103を行うことができ、またはデータシーケンスを取得するためにS102を行った後に、ステップS103に示す方法に基づいて、各データタイプおよび各データタイプに対応するサービスデータを取得するように、取得された構文解析シーケンスを構文解析するためにステップS103を行うことができることは注目に値する。ステップS102およびステップS103は、本明細書の本実装形態では同時に行うことができる。本明細書では特定の制限は課されない。

S104.ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶する。

本出願の本実装形態では、取得後に、サービス要求、各データタイプおよび各データタイプに対応するサービスデータを構文解析することによって、ブロックチェーンノードは、構文解析により取得されるサービスデータを、データベースのデータタイプに記憶することができる。

異なるサービスタイプおよび識別情報に対応するサービスデータでは、ブロックチェーンノードは、構文解析により取得されるサービスタイプおよび識別情報に基づいて、サービスタイプおよび識別情報に対応するデータベースを決定することができ、次いでブロックチェーンノードは、構文解析により取得されるサービスデータを、データベースのデータタイプにそれぞれ記憶することができる。

ステップS103を行うことによってデータ記憶ステートメントを取得した後、ブロックチェーンノードは、記憶されるサービスデータに対応しているサービスタイプおよび識別情報を決定するためにデータ記憶ステートメントを実行することができる。ブロックチェーンノードは次いで、ブロックチェーンノードがサービスタイプおよび識別情報に対応するデータベースに対応するかどうかをさらに決定することができる。はいの場合、ブロックチェーンノードはさらに、構文解析により取得されるサービスデータを、データベースのデータタイプに別々に記憶することができる。いいえの場合、ブロックチェーンノードは、決定されたサービスタイプおよび決定された識別情報に基づいて、サービスタイプおよび識別情報に対応するデータベースを作成する必要があり、これによりブロックチェーンノードは、データベースにサービスデータを記憶する。

確かに、本出願の本実装形態では、ブロックチェーンノードが単一のデータベースに対応する場合、ブロックチェーンノードは、データベースがサービスタイプおよび識別情報に対応するデータテーブルを含むかどうかを決定することができる。はいの場合、ブロックチェーンノードは、構文解析により取得されるサービスデータを、データテーブルのデータタイプに別々に記憶する。いいえの場合、ブロックチェーンノードは、所定のテーブル作成メソッドを使用することによって、サービスタイプおよび識別情報に対応するデータテーブルを作成し、次いで、構文解析により取得されるサービスデータをデータテーブルに記憶する。

たとえば、ブロックチェーンノードが、データ記憶ステートメントを実行することによって以下のフィールドを決定すると仮定する。すなわち、記憶されるサービスデータに対応するサービスタイプフィールドが「商品」であり、識別情報を示すために使用されるユーザ公開キーが“PublicKey1"である(実際のユーザ公開キーは比較的複雑であることがあるので、ユーザ公開キーはここではPublicKey1を使用することによって単に簡単に示される)。ブロックチェーンノードは、ブロックチェーンノードに対応するデータベースが、識別情報PublicKey1およびサービスタイプ商品を含むデータテーブルを含むかどうかをさらに決定することができる。データテーブルが存在しないと決定するとき、ブロックチェーンノードは、決定されたサービスタイプ商品、決定された識別情報PublicKey1、および所定のテーブル作成メソッドに基づいてデータベースに、サービスタイプ商品および識別情報PublicKey1に対応するデータテーブルを作成する。実行ステートメントは以下の通りである。

create table "PublicKey1.schema: commodity" if "PublicKey1.schema: commodity" not exist.

データ記憶ステートメントを実行することによって、ブロックチェーンノードに対応するデータベースのサービスデータに対応するデータテーブルを決定(または作成)した後、ブロックチェーンノードは、データテーブルがサービスデータに含まれている各データタイプを含んでいるかどうかを決定することができる。はいの場合、ブロックチェーンノードは、データテーブルにデータタイプに対応する行または列を作成する。いいえの場合、ブロックチェーンノードは、データタイプおよび所定の行/列作成メソッドに基づいて、データタイプに対応する行/列をデータテーブルに追加することができる。

先の例を続けると、ブロックチェーンノードは、データシーケンスに、データフィールド:name:shoes#12xewおよびcost:158を決定する。データフィールドでは、名前および原価はデータタイプであり、キーに相当し、名前および原価に対応するサービスデータは、値に相当する。ブロックチェーンノードは、サービスタイプ商品および識別情報PublicKey1に基づいて決定されたデータテーブルが、データフィールドに各データタイプを含むかどうかを決定することができる。はいの場合、ブロックチェーンノードは、データベースにデータタイプに対応する列を作成しない。いいえの場合、ブロックチェーンノードは、データタイプおよび所定の列作成メソッドに基づいてデータテーブルにデータタイプに対応する列を追加することができる(データテーブルが行ディメンションで作成される場合、行作成メソッドを使用することができる)。特定の実行ステートメントは以下の通りである。

create column "name" if "PublicKey1.schema: commodity". "name" not exist; create column "cost" if "PublicKey1.schema: commodity". "cost" not exist.

データ記憶ステートメントを実行することによって、データベースに記憶されるサービスデータに対応するデータタイプ(データタイプはデータベースにすでに存在することがあり、またはデータ記憶ステートメントを実行することによってブロックチェーンノードによって作成されることがある)を決定した後、ブロックチェーンノードは、データベースにデータタイプのサービスデータを記憶することができる。確かに、ブロックチェーンノードが、記憶されるサービスデータに対応するデータタイプが、データベースのあるデータテーブル(すなわち、サービスタイプおよび識別情報に一致するデータテーブル)にあると決定する場合、ブロックチェーンノードは、図2に示すように、構文解析により取得されるサービスデータを、データテーブルのデータタイプに記憶することができる。

図2は、本出願の一実装形態による、データテーブルを示す概略図である。

図2では、名前および原価が、サービスデータのデータタイプであり、PublicKey1が、サービスデータに対応する識別情報であり、商品が、サービスデータに対応するサービスタイプであり、各データタイプが、データタイプに対応するサービスデータを記録する。したがって、ユーザがその後サービスデータを照会するとき、ブロックチェーンノードは、ユーザによって送られたサービスデータ照会要求を受信し、さらにデータベースからサービスデータ照会要求に一致するサービスデータをさらに照会することができる。照会プロセスは、以下の通りとすることができ、すなわち、サービスデータ照会要求を受信した後、ブロックチェーンノードは、まず、サービスデータ照会要求に含まれるサービスタイプおよび識別情報を決定することができる。次いでブロックチェーンノードは、データベースのサービスタイプおよび識別情報に一致するデータテーブルを決定し、データタイプとサービスデータとの間にあり、データテーブルに記録されるマッピング関係に基づいてデータテーブルから、サービスデータ照会要求に基づいて照会されるサービスデータをさらに照会することができる。

たとえば、ブロックチェーンノードによって受信されたサービスデータ照会要求が、以下のフィールド、PublicKey: PublicKey1、スキーマ(schema):商品、および名前: blouse#4212vを含むと仮定する。ブロックチェーンノードは、サービスデータ照会要求で、サービスデータ照会要求に対応するサービスタイプは商品であり、識別情報はPublicKey1であると決定し、次いで、ブロックチェーンノードに対応するデータベースからサービスタイプ商品および識別情報PublicKey1に一致するデータテーブルを識別し、インデックスフィールドblouse#4212vに基づいてデータテーブルからインデックスフィールドblouse#4212vに対応するサービスデータ211を識別することができる。

確かに、ユーザによって送られたサービスデータ照会要求を受信した後、サービスデータがデータタイプのみに基づいて区別される場合、ブロックチェーンノードは、サービスデータ照会要求に基づいて、照会されるサービスデータに対応するデータタイプを決定し、次いで、ブロックチェーンノードに対応するデータベースからデータタイプに一致するサービスデータを照会することができる。ユーザによって送られたサービスデータ照会要求を受信した後、データタイプを決定するとき、ブロックチェーンノードは、サービスデータ照会要求に含まれるインデックスフィールド、すなわちキーを決定し、照会されるサービスデータに対応するデータタイプとしてインデックスフィールド、すなわちキーを決定することができる。

データテーブルでは、インデックスフィールドとしてキーを使用することによってサービスデータを照会することに加えて、サービスデータは、ユーザによるインデックスの作成によって照会することができる。たとえば、先の例を続けると、ユーザが価格範囲に基づいてサービスデータを照会する必要がある場合、ユーザは、ブロックチェーンノードに価格範囲を入力することができる。ブロックチェーンノードは、ユーザによって入力された価格範囲に基づいて、データベースのデータテーブルから価格範囲を満たすサービスデータを照会し、条件を満たすサービスデータを閲覧のためにユーザに返すことができる。

既存の技術では、ブロックチェーンノードは、スマートコントラクトで指定されたデータ記憶フォーマットに基づいてブロックチェーンにサービスデータを書き込む必要がある。加えて、ブロックチェーンノードは、通常、データ記憶フォーマットに基づいて、デフォルトでブロックチェーンノードに対応するメモリにサービスデータを記憶する。したがって、スマートコントラクトをコンパイルするプロセスでは、通常、ブロックチェーンノードが、指定されたデータ記憶フォーマットに基づいて、ブロックチェーンノードに対応するメモリにサービスデータを記憶することが指定される。対応して、ユーザがスマートコントラクトを使用することによってブロックチェーンノードからサービスデータを照会するとき、ユーザもまた、定まった照会方法で(たとえば、定まった形式でインデックスフィールドを使用することによって)、ブロックチェーンノードに対応するメモリから対応するサービスデータを照会する必要がある。

しかしながら、実際には、サービスデータを照会するためにユーザによって使用されるインデックスフィールドは一意ではない。結果として、サービスデータを照会するためにユーザによって使用されるインデックスフィールドは、スマートコントラクトで指定されない場合がある。ユーザがスマートコントラクトを満たさないインデックスフィールドを使用すると、ブロックチェーンノードは、スマートコントラクトを使用することによってブロックチェーンノードから以前のサービスデータを識別することができない。

たとえば、ブロックチェーンノードが、スマートコントラクトを使用することによって所定のデータ記憶フォーマットに基づいて、ブロックチェーンノードに対応するメモリにサービス要求を記憶するとき、ユーザはその後、インデックスフィールドとしてキーを使用することによってのみ、メモリからサービスデータを照会することができる。しかしながら、ブロックチェーンノードは、スマートコントラクトを使用することによってスマートコントラクトで指定された指定のデータフォーマットに基づいて1つずつサービスデータのすべてを記憶し、言い換えれば、リレーショナルデータベースのデータテーブルの形式でサービスデータを記憶しない。したがって、ユーザが値で記録された内容に基づいてサービスデータを照会する必要があるとき、スマートコントラクトは、ユーザによってブロックチェーンノードに入力された照会フィールドを効果的にサポートすることができない。結果として、ユーザは、スマートコントラクトを使用することによって、ブロックチェーンノードに対応するメモリから以前のサービスデータを識別することができない(以前のサービスデータはインデックスフィールドとしてキーを使用することによってしか照会することができないためである)。代替として、ブロックチェーンノードは、ブロックチェーンノードがユーザによって入力された照会フィールドに基づいて長時間メモリをトラバースして初めて、ブロックチェーンノードに対応するメモリから対応するサービスデータを識別することができる。

本出願の本実装形態では、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを決定するためにサービス要求を構文解析し、最終的に、データタイプとサービスデータとのマッピング関係に基づいて、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを記憶することができる。したがって、ユーザは、データベースでそのようなマッピング関係に基づいてサービスデータを照会することができ、それによって、インデックスに基づいてブロックチェーンで照会を行う既存の技術の問題を緩和し、ブロックチェーンでのデータ照会の柔軟性および効率を効果的に上げる。

本出願の本実装形態では、ユーザのサービスデータは、単に識別情報に基づいてデータベースで区別することができ、サービスタイプ分類は、すべてのユーザに行われるとは限らないことは注目に値する。したがって、先のプロセスにおいて、ブロックチェーンノードは、識別情報に基づいてデータベースを作成する、データベースにデータテーブルを作成する、またはデータベースにデータテーブルを決定することができる。確かに、サービスデータは、単にサービスタイプに基づいてデータベースで区別することができる。サービスニーズに応じて、サービスデータ間で区別するために特定の方法を使用することができる。

先の実装形態で提供したデータ記憶プロセスをさらに説明するために、本出願の一実装形態で、本出願において提供するデータ記憶方法について、図3に示すように、特定の実行プロセスを使用することによってさらに説明する。

図3は、本出願の一実装形態による、詳細なデータ記憶プロセスを示す。このプロセスは、以下のステップを含む。

S301.ブロックチェーンノードが、サービス要求を受信する。

ブロックチェーンノードは、エンドユーザデバイスを使用することによってユーザによって送られたサービス要求を受信することができる。ブロックチェーンノードは、エンドユーザデバイスであることがあり、サーバであることがあり、またはブロックチェーン技術に基づく関連サービスを処理することができるクライアントであることがある。

S302.サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを決定するために、サービス要求を構文解析する。

サービス要求を受信した後、ブロックチェーンノードは、サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを決定するために、サービス要求を構文解析することができる。ブロックチェーンノードは、所定の構文解析プログラムを使用することによって、サービス要求を構文解析することができる。構文解析プログラムは、実際のニーズに基づいてブロックチェーンノードの運用および保守要員によって設定され得る。

S303.データシーケンスを取得するために、各データタイプに対応するサービスデータおよび構文解析により取得される各データタイプを、所定のデータフォーマットに基づいて変換する。

サービス要求を構文解析することによって、サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを取得した後、ブロックチェーンノードは、データシーケンスを取得するために、各データタイプに対応するサービスデータおよび構文解析により取得される各データタイプを、所定のデータフォーマットに基づいて変換することができる。データシーケンスを取得する特定のプロセスは、以下の通りとすることができる。ブロックチェーンノードは、対応するデータシーケンスを取得するために、構文解析により取得されるデータを、特定の形式でシリアル化することができる。

S304.合意手続きのために合意ネットワークにサービス要求を送り、サービス要求に関して合意が達成されることを決定した後、ブロックチェーンノードに対応するブロックチェーンにデータシーケンスを記憶する。

サービス要求を受信すると、合意ネットワークの別のブロックチェーンノードがサービス要求に関して合意手続きを行うように、ブロックチェーンノードは、合意ネットワークにサービス要求を送ることができる。別のブロックチェーンノードがサービス要求に関して合意に達すると決定した後、ブロックチェーンノードは、その後のサービスデータ検証のためにブロックチェーンノードによって保存されたブロックチェーンのサービス要求を、データシーケンスの形式で記憶することができる。

本出願の本実装形態では、ブロックチェーンノードがサービス要求を受信するたびに、ブロックチェーンノードは、合意手続きのために合意ネットワークにサービス要求を送る。代替として、ブロックチェーンノードは、ユーザによって送られたサービス要求をまず受信し、合意フェーズにさしかかると決定するとき、受信したサービス要求をパックして前処理ブロックにし、合意手続きのために合意ネットワークに前処理ブロックを送ることができる。対応して、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、各サービス要求に含まれるデータタイプおよびデータタイプに対応するサービスデータを決定するために、サービス要求を1つずつ構文解析し、次いで、各データシーケンスを取得するために、各サービス要求に含まれるデータタイプおよびデータタイプに対応するサービスデータを、所定のデータフォーマットに基づいて変換することができる。

合意ネットワークの別のブロックチェーンノードが合意ネットワークに送られた前処理ブロックに関して合意に達すると決定した後、ブロックチェーンノードは、ブロックチェーンノードに含まれるブロックチェーンに前処理ブロックに含まれる各サービス要求を、各サービス要求に対応する各データシーケンスの形式で記憶することができる。

S305.ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶する。

構文解析により取得される各データタイプおよびサービスデータを変換すると、ユーザがその後、データタイプとサービスデータとのマッピング関係に基づいてデータベースから対応するサービスデータを識別できることを確実にするために、ブロックチェーンノードは、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。

ブロックチェーンノードは、ステップS303およびステップS305を同時に行うことができる。言い換えれば、ブロックチェーンノードがデータシーケンスを取得するために、構文解析により取得される各データタイプに対応するサービスデータおよび各データタイプを変換するとき、ブロックチェーンノードは、ブロックチェーンノードに対応するデータベースに構文解釈により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。

確かに、合意ネットワークの別のブロックチェーンノードが、サービス要求に関して合意に達すると決定した後、ブロックチェーンノードは、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。

上記は、本出願の実装形態で提供されるデータ記憶方法およびデータ照会方法を説明した。同じ概念に基づいて、本出願の実装形態は、図4および図5に示すように、データ記憶デバイスおよびデータ照会デバイスをさらに提供する。

図4は、本出願の一実装形態による、データ記憶デバイスを示す概略図である。デバイスは、サービス要求を受信するように構成された受信モジュール401と、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析するように構成されたデータ構文解析モジュール402と、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶するように構成された記憶モジュール403とを含む。

デバイスは、データシーケンスを取得するために、サービス要求に含まれる各データタイプおよび各データタイプに対応するサービスデータを、所定のデータフォーマットに基づいて変換することと、合意ネットワークを使用することによってサービス要求に関して合意手続きを行うことと、サービス要求に関して合意が達成された後にデバイスに対応するブロックチェーンにデータシーケンスを記憶することとを行うように構成された合意モジュール404をさらに含む。

データ構文解析モジュール402は、サービス要求に対応するサービスタイプまたは識別情報のうちの少なくとも1つを決定する。

記憶モジュール403は、データ記憶ステートメントを取得するために、構文解析により取得される各データタイプ、各データタイプに対応するサービスデータ、サービスタイプ、または識別情報のうちの少なくとも1つを、所定のステートメントフォーマットに基づいて変換し、データ記憶ステートメントを実行することによってデータベースに、構文解析により取得されるサービスデータを記憶する。

記憶モジュール403は、データ記憶ステートメントを実行することによって、サービスタイプまたは識別情報のうちの少なくとも1つに一致するデータベースが識別されないと決定するとき、サービスタイプまたは識別情報のうちの少なくとも1つに基づいて、サービスタイプまたは識別情報のうちの少なくとも1つに対応するデータベースを作成し、作成したデータベースに、構文解析により取得されるサービスデータを記憶する。

記憶モジュール403は、データベースがデータタイプを含んでいないと決定するとき、データベースにデータシーケンスを構文解析することによって取得される各データタイプを作成し、データベースにデータタイプに対応するサービスデータを記憶する。

図5は、本出願の一実装形態による、データ照会デバイスを示す概略図である。デバイスは、サービスデータ照会要求を受信するように構成された要求受信モジュール501と、サービスデータ照会要求に基づいて、照会されるサービスデータに対応するデータタイプを決定するように構成されたタイプ決定モジュール502と、デバイスに対応するデータベースからデータタイプに一致するサービスデータを照会するように構成されたデータ照会モジュール503であって、データベースがデータタイプとサービスデータとのマッピング関係を含む、データ照会モジュール503とを含む。

本出願の実装形態では、ユーザによって送られたサービス要求を受信した後、ブロックチェーンノードは、各データタイプおよび各データタイプに対応するサービスデータを取得するためにサービス要求を構文解析し、ブロックチェーンノードに対応するデータベースに構文解析により取得されるサービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。サービスデータは、構文解析により取得され、サービスデータは、ブロックチェーンノードに対応するデータベースに、データタイプとサービスデータとのマッピング関係に基づいて記憶することができる。したがって、ユーザは、データベースでそのようなマッピング関係に基づいてサービスデータを照会することができ、それによって、インデックスに基づいてブロックチェーンで照会を行う既存の技術の問題を緩和し、ブロックチェーンでのデータ照会の柔軟性および効率を効果的に向上させる。

1990年代では、技術的改良がハードウェアの改良(たとえば、ダイオード、トランジスタ、またはスイッチなどの回路構造の改良)であるか、ソフトウェアの改良(方法手続きの改良)であるかを、明確に区別することができる。しかしながら、技術が発展するにつれて、多くの方法手続きの現在の改良を、ハードウェア回路構造の直接的な改良と考えることができる。設計者は通常、改良した方法手続きをハードウェア回路にプログラムし、対応するハードウェア回路構造を得る。したがって、方法手続きは、ハードウェアエンティティモジュールを使用することによって改良され得る。たとえば、プログラマブル論理デバイス(PLD)(たとえば、フィールドプログラマブルゲートアレイ(FPGA))が、そのような集積回路であり、PLDの論理機能は、デバイスプログラミングによりユーザによって決定される。設計者は、チップ製造業者に特定用途向け集積回路チップを設計および製造するよう要求することなく、デジタルシステムをPLDに「統合する」ためにプログラミングを行う。加えて、現在、集積回路チップを手作業で製造する代わりに、このタイプのプログラミングは、「論理コンパイラ」ソフトウェアを使用することによって大部分が実装される。論理コンパイラソフトウェアは、プログラムを開発し、書き込むために使用されるソフトウェアコンパイラと同様である。オリジナルのコードは、コンパイルのために特定のプログラミング言語で書き込まれる必要がある。言語は、ハードウェア記述言語(HDL)と呼ばれる。Advanced Boolean Expression Language (ABEL)、Altera Hardware Description Language (AHDL)、Confluence、Cornell University Programming Language (CUPL)、HDCal、Java（登録商標） Hardware Description Language (JHDL)、Lava、Lola、MyHDL、PALASM、およびRuby Hardware Description Language (RHDL)などの、多くのHDLがある。超高速集積回路ハードウェア記述言語(VHDL:very-high-speed integrated circuit har
dware description language)およびVerilogは、最も一般的に使用される。いくつかの説明したハードウェア記述言語を使用することによって方法手続きが論理的にプログラムされ、集積回路にプログラムされると、論理的方法手続きを実装するハードウェア回路が容易に取得され得ることも、当業者には理解されよう。

コントローラは、任意の適切な方法を使用することによって実装され得る。たとえば、コントローラは、マイクロプロセッサもしくはプロセッサ、または、マイクロプロセッサもしくはプロセッサによって実行できる(ソフトウェアもしくはファームウェアなどの)コンピュータ可読プログラムコードを記憶するコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブル論理コントローラ、または組込みマイクロプロセッサとすることができる。コントローラの例は、限定はしないが、以下のマイクロプロセッサ、すなわち、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、およびSilicon Labs C8051F320を含む。メモリコントローラは、メモリの制御論理の一部として実装されることもある。コンピュータ可読プログラムコードを使用することによってコントローラを実装することに加えて、コントローラが論理ゲート、スイッチ、特定用途向け集積回路、プログラマブル論理コントローラ、および内蔵マイクロコントローラの形式で同じ機能を実装することができるように、方法ステップに論理プログラミングが行われ得ることもまた、当業者には知られている。したがって、コントローラは、ハードウェア構成要素と考えることができ、コントローラで様々な機能を実施するように構成されたデバイスは、ハードウェア構成要素の構造体と考えることもできる。または、様々な機能を実装するように構成されたデバイスは、方法を実装するソフトウェアモジュールとハードウェア構成要素の構造体の両方と考えることさえできる。

先の実装形態で示したシステム、デバイス、モジュール、またはユニットは、コンピュータチップもしくはエンティティを使用することによって実装されることがあり、またはある機能を有する製品を使用することによって実装されることがある。一般的な実装デバイスはコンピュータである。コンピュータは、たとえば、パーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ電話、スマートフォン、携帯情報端末、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲーム機、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスのいずれかの組合せであることがある。

説明しやすいように、上記のデバイスは、様々なユニットに機能を分割することによって説明されている。確かに、本出願が実装されるとき、各ユニットの機能が、1つまたは複数のソフトウェアおよび/またはハードウェアで実装されることがある。

本開示の実装形態は、方法、システム、またはコンピュータプログラム製品として提供され得ることは当業者には理解されよう。したがって、本開示は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアを組み合わせた実装形態の形を使用することができる。加えて、本開示の実装形態は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないがディスクメモリ、CD-ROM、光メモリなどを含む)に実装されるコンピュータプログラム製品の形を使用することができる。

本開示は、本開示の実装形態に基づいて、方法のフローチャートおよび/またはブロック図、デバイス(システム)、およびコンピュータプログラム製品を参照しながら説明される。フローチャートおよび/またはブロック図中の各プロセスおよび/または各ブロック、ならびにフローチャートおよび/またはブロック図中のプロセスおよび/またはブロックの組合せを実施するために、コンピュータプログラム命令が使用できることは注目に値する。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または機械を生成するための別のプログラマブルデータ処理デバイスのプロセッサに提供することができ、これにより別のプログラマブルデータ処理デバイスのコンピュータまたはプロセッサによって実行される命令が、フローチャート中の1つもしくは複数のプロセスのおよび/またはブロック図中の1つもしくは複数のブロックの特定の機能を実施すためのデバイスを生成する。

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスに特定の方法で動作するよう命令することができるコンピュータ可読メモリに記憶することができ、これによりコンピュータ可読メモリに記憶された命令が、命令デバイスを含むアーティファクトを生成する。命令デバイスは、フローチャート中の1つもしくは複数のプロセスにおよび/またはブロック図中の1つもしくは複数のブロックに、特定の機能を実装する。

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスにロードすることができ、これにより一連の動作ならびに動作およびステップが、コンピュータまたは別のプログラマブルデバイス上で実施され、それによってコンピュータ実装処理を生成する。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャートの1つもしくは複数のプロセスでおよび/またはブロック図の1つもしくは複数のブロックで、特定の機能を実施するためのステップを提供する。

一般的な構成では、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)と、1つまたは複数の入力出力インターフェースと、1つまたは複数のネットワークインターフェースと、1つまたは複数のメモリとを含む。

メモリは、非永続型メモリ、ランダムアクセスメモリ(RAM)、不揮発性メモリ、および/またはコンピュータ可読媒体にある別の形態、たとえば、読取り専用メモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)を含むことができる。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、任意の方法または技術を使用することによって情報を記憶することができる、永続型、非永続型、取外し可能、および取外し不可能な媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであることがある。コンピュータ記憶媒体の例は、限定はしないが、パラメータランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリもしくは別のメモリ技術、コンパクトディスク読取り専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)もしくは別の光学記憶装置、カセット磁気テープ、磁気テープ/磁気ディスク記憶装置、別の磁気記憶デバイス、または任意の他の非伝送媒体を含む。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセス可能な情報を記憶するために使用することができる。本明細書で説明するように、コンピュータ可読媒体は、変調されたデータ信号および搬送波などのコンピュータ可読一時的媒体を含まない。

「含む」、「備える」という用語、またはそれらの他のどんな変異形も、排他的でない包含を含むよう意図されており、要素のリストを含むプロセス、方法、製品またはデバイスは、それらの要素を含むだけでなく、明示的に列挙されていない他の要素もまた含む、またはそのようなプロセス、方法、製品またはデバイスに固有の要素をさらに含むことに、さらに留意する価値がある。「......を含む」によって記述される要素は、より多くの制約なしに、その要素を含むプロセス、方法、製品、またはデバイスに別の同じまたは同一の要素をさらに含む。

本出願の一実装形態は、方法、システム、またはコンピュータプログラム製品として提供され得ることは、当業者には理解されよう。したがって、本出願は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアを組み合わせた実装形態の形を使用することができる。加えて、本出願は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光メモリなどを含む)に実装されるコンピュータプログラム製品の形を使用することができる。

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

本明細書の実装形態は、漸進的に説明される。実装形態の同じまたは同様の部分については、実装形態を参照することがある。各実装形態は、他の実装形態との違いに焦点を当てる。詳細には、システム実装形態は、方法実装形態と基本的に同様であり、したがって簡単に説明される。関連する部分については、方法実装形態の関連する説明を参照することがある。

前述の説明は本出願の実装形態であり、本出願を限定することを目的としていない。当業者は、本出願に様々な修正および変更を行うことができる。本出願の趣旨および原理から逸脱することなく行われるいかなる修正、均等物との置換、または改良も、本出願の特許請求の範囲内に入るものとする。

401 受信モジュール
402 データ構文解析モジュール
403 記憶モジュール
404 合意モジュール
501 要求受信モジュール
502 タイプ決定モジュール
503 データ照会モジュール

Claims (12)

1. データ記憶方法であって、
   ブロックチェーンノードによってサービス要求を受信するステップと、
   各データタイプおよび各データタイプに対応するサービスデータを取得するために、前記サービス要求を構文解析するステップと、
   前記ブロックチェーンノードに対応するデータベースに構文解析により取得される前記サービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶するステップと
   を含む、方法。
2. 前記サービス要求を前記構文解析した後、
   データシーケンスを取得するために、前記サービス要求に含まれる各データタイプ、および各データタイプに対応する前記サービスデータを、所定のデータフォーマットに基づいて変換するステップと、
   合意ネットワークを使用することによって、前記サービス要求に関して合意手続きを行うステップと、
   前記サービス要求に関して合意が達成された後に、前記ブロックチェーンノードに対応するブロックチェーンに前記データシーケンスを記憶するステップと
   をさらに含む、請求項1に記載の方法。
3. 前記サービス要求が受信されたと決定したことに応答して、
   前記サービス要求に対応するサービスタイプまたは識別情報のうちの少なくとも1つを決定するステップ
   をさらに含み、
   前記ブロックチェーンノードに対応するデータベースに構文解析により取得される前記サービスデータを前記記憶するステップが、
   データ記憶ステートメントを取得するために、構文解析により取得される各データタイプ、各データタイプに対応する前記サービスデータ、前記サービスタイプ、または前記識別情報のうちの少なくとも1つを、所定のステートメントフォーマットに基づいて変換するステップと、
   前記データ記憶ステートメントを実行することによって、前記データベースに構文解析により取得される前記サービスデータを記憶するステップと
   を含む、請求項1に記載の方法。
4. 前記データ記憶ステートメントを実行することによって、前記データベースに構文解析により取得される前記サービスデータを前記記憶するステップが、
   前記データ記憶ステートメントを実行することによって、サービスタイプまたは前記識別情報のうちの前記少なくとも1つに一致するデータベースが識別されないと決定したことに応答して、前記サービスタイプまたは前記識別情報のうちの少なくとも1つに基づいて、サービスタイプまたは前記識別情報のうちの前記少なくとも1つに対応するデータベースを作成するステップと、
   前記作成されたデータベースに構文解析により取得される前記サービスデータを記憶するステップと
   を含む、請求項3に記載の方法。
5. データベースに構文解析により取得される前記サービスデータを前記記憶するステップが、
   前記データベースが前記データタイプを含まないと決定したことに応答して、前記データベースに前記データシーケンスを構文解析することによって取得される各データタイプを作成するステップと、
   前記データベースに前記データタイプに対応するサービスデータを記憶するステップと
   を含む、請求項1または4に記載の方法。
6. データ照会方法であって、
   ブロックチェーンノードによってサービスデータ照会要求を受信するステップと、
   前記サービスデータ照会要求に基づいて、照会されるサービスデータに対応するデータタイプを決定するステップと、
   前記ブロックチェーンノードに対応するデータベースから前記データタイプに一致するサービスデータを照会するステップであって、前記データベースがデータタイプとサービスデータとのマッピング関係を含む、照会するステップと
   を含む、方法。
7. データストレージデバイスであって、
   サービス要求を受信するように構成された、受信モジュールと、
   各データタイプおよび各データタイプに対応するサービスデータを取得するために、前記サービス要求を構文解析するように構成された、データ構文解析モジュールと、
   前記ブロックチェーンノードに対応するデータベースに構文解析により取得される前記サービスデータを、データタイプとサービスデータとのマッピング関係に基づいて記憶するように構成された、記憶モジュールと
   を備える、デバイス。
8. 合意モジュールであって、
   データシーケンスを取得するために、前記サービス要求に含まれる各データタイプ、および各データタイプに対応する前記サービスデータを、所定のデータフォーマットに基づいて変換することと、
   合意ネットワークを使用することによって、前記サービス要求に関して合意手続きを行うことと、
   前記サービス要求に関して合意が達成された後に、前記デバイスに対応するブロックチェーンに前記データシーケンスを記憶することと
   を行うように構成された合意モジュール
   をさらに備える、請求項7に記載のデバイス。
9. 前記データ構文解析モジュールが、前記サービス要求に対応するサービスタイプまたは識別情報のうちの少なくとも1つを決定し、
   前記記憶モジュールが、データ記憶ステートメントを取得するために、構文解析により取得される各データタイプ、各データタイプに対応する前記サービスデータ、前記サービスタイプ、または前記識別情報のうちの少なくとも1つを、所定のステートメントフォーマットに基づいて変換し、前記データ記憶ステートメントを実行することによって前記データベースに、構文解析により取得される前記サービスデータを記憶する、請求項7に記載のデバイス。
10. 前記記憶モジュールが、
    前記データ記憶ステートメントを実行することによって、前記サービスタイプまたは前記識別情報のうちの少なくとも1つに一致するデータベースが識別されないと決定したことに応答して、前記サービスタイプまたは前記識別情報のうちの少なくとも1つに基づいて、前記サービスタイプまたは前記識別情報のうちの少なくとも1つに対応するデータベースを作成することと、
    前記作成されたデータベースに構文解析により取得される前記サービスデータを記憶することと
    を行うように構成される、請求項9に記載のデバイス。
11. 前記記憶モジュールが、前記データベースが前記データタイプを含んでいないと決定したことに応答して、前記データベースに前記データシーケンスを構文解析することによって取得される各データタイプを作成し、前記データベースに前記データタイプに対応するサービスデータを記憶する、請求項7または10に記載のデバイス。
12. データ照会デバイスであって、
    サービスデータ照会要求を受信するように構成された、要求受信モジュールと、
    前記サービスデータ照会要求に基づいて、照会されるサービスデータに対応するデータタイプを決定するように構成された、タイプ決定モジュールと、
    前記デバイスに対応するデータベースから前記データタイプに一致するサービスデータを照会するように構成された、データ照会モジュールであって、前記データベースがデータタイプとサービスデータとのマッピング関係を含む、データ照会モジュールと
    を備える、デバイス。