JP2020512610A - ブロックチェーンサービス受付けおよびコンセンサス方法およびデバイス - Google Patents

Abstract

ブロックチェーンサービス受付けおよびコンセンサス方法およびデバイスが開示される。コンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、データベースとを備え、データベースは、コンセンサスノードのキャッシュ圧力を低減するために、第1のアプリケーションおよび第2のアプリケーションによって処理されたサービスデータを記憶するために使用される。したがって、本発明の実施形態によって提供される方法に基づいて、コンセンサスノードが、サービス要求に対応するサービスデータを決定する限り、サービスデータは、他のコンセンサスノードに送信されるのを待つためにデータベースに記憶され得、それにより、コンセンサスノードのキャッシュの占有率が低くなり、単位時間内にコンセンサスノードによって処理され得るサービスの数が増加され、コンセンサスノード上でコンセンサス検証を行い、サービス要求を処理する効率が改善され得る。

Description

本出願は、情報技術の分野に関し、特に、ブロックチェーンサービス受付けおよびコンセンサス方法および装置に関する。

情報技術の発展とともに、新生の技術として、ブロックチェーン技術が、開放性、不変性、および分散化など、それらの利点のために、人々から大きな注目を集めてきた。

既存のブロックチェーン技術では、ブロックチェーンネットワーク中の各コンセンサスノードが、クライアントによって送信されたサービス要求をハンドリングすることができる。説明のための一例として、1つのコンセンサスノードが使用される。サービス要求を受信した後に、コンセンサスノードは、最初に、サービス要求に基づいて、対応するサービスデータを決定し得る。次いで、コンセンサスノードは、サービスデータを別のコンセンサスノードにブロードキャストし得る。別のコンセンサスノードによって送信された前処理されたブロックを受信した後に、コンセンサスノードは、前処理されたブロックに対してコンセンサス検証をさらに実行し得、前処理されたブロックが検証をパスした後に、前処理されたブロックを記憶し得る。

サービス要求をハンドリングした後に、コンセンサスノードは、通常、サービス要求に対応するサービスデータをコンセンサスノードのキャッシュに記憶する。その後、サービスデータがコンセンサス検証をパスした後に、サービスデータはキャッシュから解放される。同様に、別のコンセンサスノードによって送信されたサービスデータも、キャッシュに記憶され、コンセンサス検証をパスした後に解放され得る。

コンセンサスノードについて、ブロックチェーンに記憶されないデータは、通常、コンセンサスノードのキャッシュに一時的に記憶される。したがって、コンセンサス検証が実行されたとき、検証可能なサービスデータの量がコンセンサスノードのキャッシュ容量によって制限され、コンセンサス検証の効率が制限される。さらに、コンセンサスノードのキャッシュ空間が不十分であるとき、コンセンサスノードは、受信されたサービス要求を処理するのが困難である。

本出願の実装形態は、既存のブロックチェーン技術における低いサービス実行効率の問題を解決するために、ブロックチェーンサービスハンドリング方法およびブロックチェーンサービスコンセンサス方法を提供する。

本出願の実装形態は、既存のブロックチェーン技術における低いサービス実行効率の問題を解決するために、ブロックチェーンサービスハンドリング装置およびブロックチェーンサービスコンセンサス装置を提供する。

以下の技術的解決策は、本出願の実装形態において使用される。

ブロックチェーンサービスハンドリング方法であって、コンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、データベースとを含み、本方法が、第1のアプリケーションによって、クライアントによって送信されたサービス要求を受信するステップ、およびサービス要求に基づいて、対応する要送信(to-be-sent)サービスデータを決定するステップと、第1のアプリケーションによって、要送信サービスデータをデータベースに記憶するステップと、所定の条件が満たされたとき、第2のアプリケーションまたは第1のアプリケーションによって、データベースから要送信サービスデータをフェッチするステップ、および要送信サービスデータを、記憶のために別のコンセンサスノードに送信するステップとを含む、ブロックチェーンサービスハンドリング方法が提供される。

ブロックチェーンサービスコンセンサス方法であって、第1のコンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、第1のデータベースとを含み、本方法が、第1のアプリケーションによって、コンセンサスデータを受信するステップ、およびコンセンサスデータを第1のデータベースに記憶するステップと、第2のアプリケーションによって、第1のデータベースからコンセンサスデータをフェッチするステップ、およびコンセンサス検証を実行するステップと、第2のアプリケーションによって、コンセンサスデータに検証結果を追加するステップ、検証結果を第1のデータベースに記憶するステップ、およびコンセンサス検証を実行し続けるために検証結果を別のコンセンサスノードに送信するステップとを含む、ブロックチェーンサービスコンセンサス方法が提供される。

ブロックチェーンサービスハンドリング装置であって、コンセンサスノードが、本装置と、第2のアプリケーションと、データベースとを含み、本装置が、クライアントによって送信されたサービス要求を受信し、サービス要求に基づいて、対応する要送信サービスデータを決定するように構成された、受信モジュールと、要送信サービスデータをデータベースに記憶するように構成された、記憶モジュールとを含み、所定の条件が満たされたとき、第2のアプリケーションまたは送信モジュールが、データベースから要送信サービスデータをフェッチし、要送信サービスデータを、記憶のために別のコンセンサスノードに送信する、ブロックチェーンサービスハンドリング装置が提供される。

ブロックチェーンサービスコンセンサス装置であって、第1のコンセンサスノードが、受信モジュールと、処理および送信モジュールと、第1のデータベースとを含み、受信モジュールが、コンセンサスデータを受信し、コンセンサスデータを第1のデータベースに記憶するように構成され、処理および送信モジュールが、第1のデータベースからコンセンサスデータをフェッチし、コンセンサス検証を実行するように構成され、処理および送信モジュールが、コンセンサスデータに検証結果を追加し、検証結果を第1のデータベースに記憶し、コンセンサス検証を実行し続けるために検証結果を別のコンセンサスノードに送信するように構成された、ブロックチェーンサービスコンセンサス装置が提供される。

本出願の実装形態において使用される、前に説明された技術的解決策のうちの少なくとも1つは、以下の有益な効果を達成することができる

コンセンサスノードは、第1のアプリケーションと、第2のアプリケーションと、データベースとを含む。データベースは、コンセンサスノードのキャッシュ圧力を低減するために、第1のアプリケーションおよび第2のアプリケーションが処理を実行した後に取得されるサービスデータを記憶するように構成される。本出願の実装形態において提供される方法を使用することによって、コンセンサスノードがサービス要求に対応するサービスデータを決定するという条件で、コンセンサスノードがサービスデータをデータベースに記憶することができ、コンセンサスノードがサービスデータを別のコンセンサスノードに送信するのを待ち、したがって、コンセンサスノードのキャッシュ占有率が比較的低くなることがわかり得る。したがって、単位時間内にコンセンサスノードによって処理され得るサービスの数が増加され、コンセンサスノードのコンセンサス検証効率およびサービス要求処理効率が改善される。

ここで説明される添付の図面は、本出願のさらなる理解を与え、本出願の一部をなすことを意図される。本出願の例示的な実装形態およびその説明は、本出願について説明することを意図し、本出願に対する制限となるものではない。添付の図面において、詳細は以下の通りである。

本出願の一実装形態による、ブロックチェーンサービスハンドリングプロセスを示す図である。 本出願の一実装形態による、ブロックチェーンサービスコンセンサスプロセスを示す図である。 本出願の一実装形態による、ブロックチェーンサービスハンドリング装置を示す概略構造図である。 本出願の一実装形態による、ブロックチェーンサービスコンセンサス装置を示す概略構造図である。

本出願の目的、技術的解決策、および利点をより明確にするために、以下は、本出願の特定の実装形態および添付の図面を参照しながら本出願の技術的解決策について明確におよび完全に説明する。明らかに、説明される実装形態は、本出願の実装形態の全部ではなく一部であるにすぎない。創造的努力なしに本出願の実装形態に基づいて当業者によって取得されるすべての他の実装形態が、本出願の保護範囲内に入るものとする。

本出願の実装形態において提供される技術的解決策は、添付の図面を参照しながら以下で詳細に説明される。

図1は、本出願の一実装形態による、ブロックチェーンサービスコンセンサスプロセスを示す。コンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、データベースとを含む。ブロックチェーンサービスコンセンサスプロセスは、詳細には、以下のステップを含み得る。

S101。第1のアプリケーションは、クライアントによって送信されたサービス要求を受信し、サービス要求に基づいて、対応する要送信サービスデータを決定する。

本出願の実装形態では、ブロックチェーンネットワーク中の各コンセンサスノードが、1つまたは複数のブロックチェーンアプリケーションおよびデータベースを含み得る。ブロックチェーンアプリケーションは、サービス要求をハンドリングし、前処理されたブロックに対してコンセンサス検証を実行することができる。データベースは、ブロックチェーンアプリケーションによって決定されたサービスデータ(たとえば、コンセンサス検証プロセスにおいて生成されたデータ、および、サービス要求がハンドリングされた後に生成されたデータ)を記憶するように構成される。

さらに、ユーザが、通常、クライアントを使用することによって命令または要求を送信する必要がある。その後、コンセンサスノードは、クライアントによって送信されたサービス要求を受信し、サービス要求に基づいて後続のステップを実行することができる。

コンセンサスノードは、複数のクライアントによって送信されたサービス要求を受信し、サービス要求に基づいてサービス処理を実行することができる。コンセンサスノードは、エンドユーザデバイス、たとえば、モバイルフォン、タブレットコンピュータ、またはパーソナルコンピュータなどのデバイスであり得る。コンセンサスノードは、代替的にサーバであり得、サーバは、別個のデバイスであり得るか、または、複数のデバイスを含むシステム、たとえば、分散型サーバであり得る。本出願は、特定のデバイスタイプのコンセンサスノードに対する特定の制限を設定しない。

詳細には、サービス要求を受信すると、コンセンサスノードは、コンセンサスノードにインストールされた第1のアプリケーションを使用することによってサービス要求を受信し得る。さらに、後続のステップにおいて、第1のアプリケーションは、サービス要求に基づいて、対応するサービス論理を決定し、サービスを実行するためにスレッドを割り振る。確実に、コンセンサスノードにインストールされた複数のアプリケーションプログラム(たとえば、第2のアプリケーション)があり得る。したがって、アプリケーションプログラムは、異なるクライアントによって送信されたサービス要求を別々に受信し、後続の動作を別々に実行し得る。説明しやすいように、本出願の実装形態では、説明のための一例として、コンセンサスノードが第1のアプリケーションおよび第2のアプリケーションのみを含むことが使用される。ただし、本出願の実装形態は、コンセンサスノード中により多くのアプリケーションがある可能性に対する制限を設定しない。

さらに、コンセンサスノードは、代替的に、複数のデバイスを含むシステムであり得、対応して、ブロックチェーンアプリケーションが各デバイスにインストールされる。したがって、デバイスは、インストールされたブロックチェーンアプリケーションを使用することによって、異なるクライアントによって送信されたサービス要求を別々に受信し、後続の動作を独立して実行し得る。

さらに、コンセンサスノードが複数のインストールされたアプリケーションプログラムまたは複数のデバイスを含むかどうかにかかわらず、コンセンサスノードは、ブロックチェーンネットワークにおいて、サービス要求をハンドリングし、コンセンサス検証を開始することができるノードと見なされ得る。コンセンサスノードの特定の構成要素が、必要に基づいて構成され得る。たとえば、サービス要求が、コンセンサスノードの比較的大きい動作圧力のために、処理されるのを頻繁に待つとき、コンセンサスノードのためにより多くのアプリケーションまたはデバイスが構成され得る。

またさらに、本出願の実装形態では、受信されたサービス要求に対してサービス処理を実行した後に、第1のアプリケーションは、サービス処理結果をサービスデータとして使用し得る。さらに、サービスデータが別のコンセンサスノードに送信されなかったので、第1のアプリケーションは、依然として、サービスデータの状態が「要送信」状態であると決定し得る。サービスデータとサービスデータの対応する「要送信」状態とは、データベースに記憶される。

代替的に、サービスデータを決定した後に、第1のアプリケーションは、サービスデータに「要送信」識別子を追加し得る。次いで、「要送信」識別子が追加されるサービスデータは、要送信サービスデータとしてデータベースに記憶される。第2のアプリケーションは、「要送信」識別子に基づいて、サービスデータを要送信サービスデータとして決定することができる。

本出願は、コンセンサスノード中の各アプリケーションまたはデバイスが、データベースにアクセスするとき、記憶されたサービスデータの状態を決定し得るという条件で、コンセンサスノードがサービスデータの状態を決定し得る方法に対する制限を設定しない。

たとえば、ユーザが取引サービスを実行する必要がある場合、ユーザによって送信されたサービス要求は、両方の取引当事者の識別情報、取引金額、および支払い元アカウント情報などのデータを含み得る。コンセンサスノードの第1のアプリケーションは、サービス要求中に含まれるデータに基づいて、対応する取引サービスを決定し、作成し得る。サービスデータを決定した後に、第1のアプリケーションは、サービスデータに「要送信」識別子を追加する。

「要送信」識別子は、代替的に、サービスデータ中のサービス属性として、サービスデータに追加され得る。たとえば、Table 1(表1)はサービスデータの概略構造を示す。

Table 1(表1)に示されているサービスデータの概略構造中の状態識別子は、コンセンサスノードの第1のアプリケーションによってサービスデータに追加され得る。状態識別子に基づいて、コンセンサスノード中の任意のアプリケーションが、サービスデータの現在状態が「要送信」状態であると決定することができる。その後、動作がサービスデータに対して実行されたとき、状態識別子に基づいて、サービスデータが別のコンセンサスノードに送信される必要があることが決定され得る。

確実に、本出願の実装形態では、サービスデータ中に含まれる特定のコンテンツとサービス属性中に含まれる特定の属性とは、本出願において特に制限されない。

S102。第1のアプリケーションは、要送信サービスデータをデータベースに記憶する。

本出願の実装形態では、ステップS101において要送信サービスデータを決定するプロセスは、コンセンサスノードのキャッシュに依存し、したがって、サービスデータはキャッシュにも記憶される。したがって、第1のアプリケーションは、さらに、別のサービスを実行するためにキャッシュ空間を解放するために、サービスデータをコンセンサスノードのデータベースに転送し、記憶し得る。

詳細には、データベースは、データを記憶するためにコンセンサスノードによって使用される記憶デバイスであり得、不揮発性メモリを使用する記憶デバイスであり得る。確実に、データベースとコンセンサスノードとは、同じデバイス中にあり得る(たとえば、データベースはパーソナルコンピュータのハードディスク中にあり得る)か、または、異なるデバイス(たとえば、外部リムーバブルハードディスク)中にあり得る。実装形態は、本出願において特に制限されない。

さらに、複数のブロックチェーンアプリケーションがコンセンサスノードにインストールされたとき、アプリケーションは、異なるクライアントによって送信されたサービス要求を別々に受信し得る。さらに、アプリケーションは、データベースに、アプリケーションによって別々に決定されたサービスデータを記憶する。したがって、データベースは、アプリケーションによって共有されるデータベースと見なされ得、すべてのアプリケーションが、データベースにアクセスするための許可を有することができる。言い換えれば、第2のアプリケーションも、要送信サービスデータを決定し、要送信サービスデータをデータベースに記憶し得る。

さらに、ステップS101において説明されたように、コンセンサスノードは、複数のデバイスを含むシステムであり得る。したがって、コンセンサスノードが、複数のデバイスを含むシステムであるとき、コンセンサスノードのすべてのデバイスがデータベースにアクセスし得、データベースは、コンセンサスノード内で、デバイスによって共有される記憶デバイスと見なされ得る。

したがって、コンセンサスノードの第1のアプリケーションは、要送信サービスデータをデータベースに記憶し、別のサービスを実行するために、サービスデータによって占有されるキャッシュ空間を解放する。したがって、コンセンサスノードは、コンセンサスノードのハードウェア構成を追加することなしに、より多くのサービス要求をハンドリングすることができる。

S103。所定の条件が満たされたとき、第2のアプリケーションまたは第1のアプリケーションは、データベースから要送信サービスデータをフェッチし、要送信サービスデータを、記憶のために別のコンセンサスノードに送信する。

本出願の実装形態では、コンセンサスノードの第1のアプリケーションが要送信サービスデータをデータベースに記憶した後に、コンセンサスノードの第1のアプリケーションは、別のクライアントによって送信されたサービス要求を受信し続け、ステップS101およびステップS102における動作と同じである動作を実行することができる(同様に、コンセンサスノードの第2のアプリケーションも、ステップS101およびステップS102における動作と同じである動作を同期的に実行し得る)。したがって、コンセンサスノードに対応するデータベースは、いくつかの要送信サービスデータを記憶し得る。他のコンセンサスノードが正常にコンセンサス検証を実行することを保証するために、コンセンサスノードのデータベースに記憶されたサービスデータは、さらに、記憶のために別のコンセンサスノードに送信される必要がある。

したがって、本出願の実装形態では、所定の条件が満たされたとき、コンセンサスノードの第1のアプリケーションまたは第2のアプリケーションは、さらに、データベースから要送信サービスデータをフェッチし、要送信サービスデータを、記憶のために別のコンセンサスノードに送信し得、それにより、その後、別のコンセンサスノードがコンセンサス検証を実行する。さらに、要送信サービスデータが送信された後、要送信サービスデータは、送信済み(sent)サービスデータに更新され得る。

詳細には、コンセンサスノード中の第1のアプリケーションまたは第2のアプリケーションのうちの少なくとも1つは、コンセンサスノードの現在状態に基づいて、所定の条件が満たされるかどうかを決定し得る。はいの場合、第1のアプリケーションおよび/または第2のアプリケーションは、要送信サービスデータをフェッチし、送信することができ、いいえの場合、第1のアプリケーションおよび/または第2のアプリケーションは、要送信サービスデータをフェッチすることができない。

コンセンサスノードのデータベースに記憶された要送信サービスデータの量が所定のしきい値に達したとき、コンセンサスノードの現在状態が所定の条件を満たすことが決定される。代替的に、指定された瞬間が来たとき、コンセンサスノードの送信期間に基づいて、所定の条件が満たされることが決定される。言い換えれば、データ中の要送信サービスデータは周期的にフェッチされる。

確実に、所定の条件は、代替的に、実際の必要に基づいて設定され得る。たとえば、所定の条件はまた、時間またはサービスボリュームが変化するとき、変化し得る。夜間(たとえば、午前0時00分〜午前4時00分)において、サービスデータをフェッチするための時間間隔が増加されるか、または、サービスボリュームが増加されるとき、サービスデータをフェッチするための時間間隔が低減される、などである。実装形態は、本出願において特に制限されない。

さらに、要送信サービスデータをフェッチするとき、第1のアプリケーションまたは第2のアプリケーションは、コンセンサスノードに対応するデータベース中のすべての要送信サービスデータをフェッチし、送信することができる。代替的に、指定された量の要送信サービスデータがフェッチされ得る。実装形態は、本出願において特に制限されない。さらに、前に説明された条件のうちの1つ、またはそれらの任意の組合せが、使用のために選択され得る。

さらに、データベースから要送信サービスデータをフェッチするとき、第1のアプリケーションまたは第2のアプリケーションは、いくつかの要送信サービスデータの生成順序に基づいていくつかの要送信サービスデータをフェッチし、フェッチされた要送信サービスデータをフェッチ順序に基づいて別のコンセンサスノードに送信することができる。詳細には、コンセンサスノードは、要送信サービスデータを1つずつフェッチし、送信し得るか、または、いくつかの要送信サービスデータをフェッチし、パックし、次いで、いくつかの要送信サービスデータを別のコンセンサスノードに送信し得る。

またさらに、第1のアプリケーションまたは第2のアプリケーションは、送信された要送信サービスデータを、送信済みサービスデータにさらに更新することができる。

たとえば、データベースからサービスデータFをフェッチし、サービスデータFを送信した後に、第1のアプリケーションは、データベース中のサービスデータFに対応する状態を、「送信済み」状態に更新し得る。代替的に、サービスデータFのサービス属性における状態識別子は、送信済み識別子に更新される。言い換えれば、サービスデータFを呼び出すとき、第1のアプリケーションはサービスデータFの状態識別子を更新し得る。

確実に、ネットワーク遅延またはデバイス故障などの問題のために、サービスデータ送信障害が起こり得る。したがって、本出願の実装形態では、送信済みサービスデータについての別のコンセンサスノードによって返された応答情報を受信した後に、第1のアプリケーションまたは第2のアプリケーションは、応答情報に基づいてサービスデータの状態識別子を更新し得る。特定の使用される方法は、本出願において特に制限されない。

図1に示されているブロックチェーンサービスハンドリング方法に基づいて、コンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、データベースとを含み得ることがわかり得る。データベースは、コンセンサスノードのキャッシュ圧力を低減するために、第1のアプリケーションおよび第2のアプリケーションがサービス処理を実行した後に取得されるサービスデータを記憶するように構成される。コンセンサスノードは、不十分なキャッシュ空間のためにサービス待機を生じることなしに、コンセンサスを待つときでも、連続的にサービス要求を受信し、サービスをハンドリングすることができる。さらに、すべてのサービスデータがデータベースに記憶されるので、インストールされるアプリケーションの数は、必要に基づいてコンセンサスノードについて増加され得る。したがって、コンセンサスノードは、コンセンサスノードの作業効率を改善するために、より多くのサービス要求を同時に受信し、処理し得る。さらに、所定の条件が満たされたとき、コンセンサスノード中の第1のアプリケーションまたは第2のアプリケーションは、データベースに記憶された要送信サービスデータをフェッチし、要送信サービスデータを、記憶のために別のコンセンサスノードに送信することができる。本出願において提供される方法を使用することによって、コンセンサスノードの動作効率が、もはやキャッシュボリュームに制限されないことがわかり得る。さらに、コンセンサスノード中のすべてのアプリケーションは、サービス要求をハンドリングし、サービスデータを送信することができ、したがって、コンセンサスノードは、要送信サービスデータを送信するためにいくつかのアプリケーションを使用し、サービス要求をハンドリングするためにいくつかの他のアプリケーションを使用し、それにより、コンセンサスノードのコンセンサス検証効率およびサービス要求処理効率を改善することができる。

さらに、本出願の実装形態では、要送信サービスデータを送信するとき、第1のアプリケーションまたは第2のアプリケーションは、最初に、サービスデータの状態を「送信済み」状態に更新することができ、それにより、別のコンセンサスノードによって受信され、記憶されたサービスデータは、「送信済み」状態にある。したがって、サービスデータに基づいてコンセンサス検証を実行するとき、別のコンセンサスノードは、第1のアプリケーションまたは第2のアプリケーションによって送信されたサービスデータを抜かさない。

さらに、本出願の実装形態では、別のコンセンサスノードによって送信されたサービスデータを受信した後に、第1のアプリケーションは、サービスデータのハッシュ値および特定のコンテンツに基づいて、要送信サービスデータに対して検証を実行し得る。検証をパスした後に、サービスデータはデータベースに記憶される。

またさらに、本出願のステップS101において、既存の技術におけるものと同じように、サービス要求を決定するとき、コンセンサスノードは、サービス要求中に含まれ、サービス処理のために必要とされるデータに対して検証を実行し得る。さらに、データが検証をパスした後、コンセンサスノードは、続いて、サービス作成およびサービス処理など、後続の動作を実行する。詳細には、検証プロセスおよび実装形態の詳細は、既存の技術におけるものに従い得る。詳細は、本出願では省略される。

さらに、本出願の実装形態では、要送信サービスデータを決定した後に、コンセンサスノードは、サービス要求に対応する応答情報をクライアントに返し得、それにより、クライアントは、コンセンサスノードがサービス要求をハンドリングすると決定する。コンセンサスノードがサービス要求に基づいてサービスデータを決定したとき、コンセンサスノードがサービス要求をハンドリングすることが考えられ得ることに留意することは、有益である。

本出願の実装形態において提供される方法のすべてのステップが同じデバイスによって実行され得るか、または、方法が異なるデバイスによって実行され得ることに留意することは、有益である。たとえば、ステップS101とステップS102とはデバイス1によって実行され得、ステップS103はデバイス2によって実行され得る。別の例では、ステップS101はデバイス1によって実行され得、ステップS102とステップS103とはデバイス2によって実行され得る。

図1に示されているブロックチェーンサービスハンドリング方法に基づいて、本出願の一実装形態は、対応して、図2に示されているように、ブロックチェーンサービスコンセンサス方法をさらに提供する。

図2は、本出願の一実装形態による、ブロックチェーンサービスコンセンサスプロセスを示す。第1のコンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、第1のデータベースとを含む。ブロックチェーンサービスコンセンサスプロセスは、詳細には、以下のステップを含む。

S201。第1のアプリケーションは、コンセンサスデータを受信し、コンセンサスデータを第1のデータベースに記憶する。

本出願の実装形態では、図1に示されているブロックチェーンサービスハンドリングプロセスにおけるコンセンサスノードと同様に、第1のコンセンサスノードは、第1のアプリケーションと、第2のアプリケーションと、第1のデータベースとを含む。さらに、第1のコンセンサスノードは、より多くのアプリケーションを含み得る。実装形態は、本出願において制限されない。しかしながら、後で説明しやすいように、本出願の実装形態では、説明のための一例として、第1のアプリケーションおよび第2のアプリケーションが使用される。

通常、ブロックチェーンネットワーク中のコンセンサスノードは、ブロックチェーンサービスコンセンサス機構に対してコンセンサス検証を開始するためのコンセンサスノードを決定することができる。したがって、第1のコンセンサスノードの第1のアプリケーションは、コンセンサスデータを受信し、コンセンサスデータを第1のデータベースに記憶することができる。

さらに、いくつかのコンセンサスアルゴリズムでは、コンセンサスノードは、別のコンセンサスノードの検証結果に基づいて、コンセンサスデータを記憶すべきかどうかを決定し得る。たとえば、いくつかのコンセンサスアルゴリズムでは、各コンセンサスノードは、検証結果が、ネットワーク全体中のコンセンサスノードの50%超が検証をパスしたことを示すかどうかを決定する必要がある。はいの場合、コンセンサスノードは、前処理されたブロックを記憶し、いいえの場合、コンセンサスノードは、前処理されたブロックを記憶しない。

したがって、検証結果は、代替的に、コンセンサスデータと見なされ得る。本出願では、コンセンサスデータは、コンセンサス検証が実行される必要があるデータ(通常、データは前処理されたブロックである)と、対応する検証結果とを含み得る。

確実に、第1のアプリケーションによって受信されたコンセンサスデータの形態にかかわらず、第1のアプリケーションは、コンセンサスデータを第1のデータベースに記憶し得る。

S202。第2のアプリケーションは、第1のデータベースからコンセンサスデータをフェッチし、コンセンサス検証を実行する。

本出願の実装形態では、第2のアプリケーションは、第1のデータベースからコンセンサスデータをフェッチし、コンセンサスデータに対して検証を実行して、後続の動作を実行することができる。

詳細には、第2のアプリケーションは、第1のデータベースからの(詳細には、前処理されたブロックであり得る)コンセンサスデータ、および第1のデータベース中の「送信済み」状態にあるサービスデータをフェッチし、「送信済み」状態にあるサービスデータに基づいてコンセンサスデータに対してコンセンサス検証を実行し、検証結果を決定することができる。

S203。第2のアプリケーションは、コンセンサスデータに検証結果を追加し、検証結果を第1のデータベースに記憶し、コンセンサス検証を実行し続けるために検証結果を別のコンセンサスノードに送信する。

本出願の実装形態では、検証結果を決定した後に、第2のアプリケーションは、検証結果を第1のデータベースに記憶し、コンセンサス検証を実行し続けるために検証結果を別のコンセンサスノードに送信し得る。第2のアプリケーションが検証データを送信する前に検証データを記憶するのか、第2のアプリケーションが検証データを記憶する前に検証データを送信するのかは、本出願において制限されない。

さらに、本出願の実装形態におけるステップS201〜ステップS203において、ブロックチェーンサービスコンセンサス機構は、実用的ビザンチンフォールトトレランス(PBFT:Practical Byzantine Fault Tolerance)アルゴリズムであり得、1次ノードは、式、ビューID/Mに基づいてブロックチェーンネットワーク中のコンセンサスノードから決定され得、1次ノードはコンセンサス検証を開始する。各コンセンサスノードは、コンセンサスノードの現在の期間(すなわち、ビュー)を最初に決定することができ、ビューIDは、コンセンサスノードによって決定された現在の期間の識別子を表す。通常、期間の識別子は、0からM-1までの数であり、Mは、ブロックチェーンネットワーク中のコンセンサスノードの総数を表す。

詳細には、第2のコンセンサスノードが、1次ノードであり、コンセンサス検証を開始し、第1のコンセンサスノードが、コンセンサス検証を実行するための2次ノードであることは、説明のための一例として使用される。第2のコンセンサスノードは、第3のアプリケーションと、第4のアプリケーションと、第2のデータベースとを含む。第3のアプリケーションは、第2のデータベース中の「送信済み」状態にあるサービスデータに基づいて、前処理されたブロックを作成し、前処理されたブロックを第2のデータベースに記憶する。第4のアプリケーションは、第2のデータベースから、前処理されたブロックをフェッチし、前処理されたブロックを第2のコンセンサスノード以外のコンセンサスノードに送信する。

第1に、第2のコンセンサスノードの第3のアプリケーションは、現在のビューIDを使用することによって、第2のコンセンサスノードを1次ノードとして決定し得る。したがって、第3のアプリケーションは、所定のコンセンサス条件に基づいて、第2のデータベースから、コンセンサスに達する必要がある送信済みサービスデータをフェッチし得る。所定のコンセンサス条件は、必要に基づいて設定され得る。実装形態は、本出願において特に制限されない。たとえば、コンセンサスに達する必要があるサービスデータが、時間順序に基づいて選択され得るか、または、容量を満たす送信済みサービスデータが、前処理されたブロックの容量に基づいて選択される、などである。

さらに、第3のアプリケーションは、フェッチされた、および送信済みのサービスデータに基づいて、対応する前処理されたブロックを作成し、たとえば、前処理されたブロック中の送信済みサービスデータの配置順序を決定し、マークルツリーを使用することによって、前処理されたブロックのヘッダハッシュ値を決定し得る。詳細には、本出願の実装形態では、既存の技術におけるものと同じである方法が、前処理されたブロックを作成するために使用され得る。実装形態は、本出願において特に制限されない。

さらに、第3のアプリケーションは、PBFTの3段階プロトコルの第1の段階に基づいて、既存の技術におけるものと同じ方法を使用して、前処理されたブロックに対応する、事前準備された情報を決定することができる。事前準備された情報のフォーマットは、<pre-prepared, v, n, d>であり得、vは現在ビューIDの数を表し、nは前処理されたブロックの識別子を表し、dは前処理されたブロックのダイジェストである。事前準備された情報に署名した後に、第3のアプリケーションは、事前準備された情報と前処理されたブロックとを第2のデータベースに記憶することができる。

次いで、第4のアプリケーションは、第2のデータベースから事前準備された情報と前処理されたブロックとをフェッチし、事前準備された情報と前処理されたブロックとを第2のコンセンサスノード以外のコンセンサスノードに送信することができる。したがって、別のコンセンサスノードが、事前準備された情報に対して検証を実行する。ステップS201において説明されたように、第1のアプリケーションは、事前準備された情報と前処理されたブロックとを受信し、事前準備された情報と前処理されたブロックとをコンセンサスデータとして第1のデータベースに記憶し得る。

次いで、ステップS202において説明されたように、第2のアプリケーションは、第1のデータベースからコンセンサスデータをフェッチし(たとえば、第2のアプリケーションは、事前準備された情報と前処理されたブロックとをフェッチすることができる)、コンセンサス検証を実行することができる。詳細には、第2のアプリケーションは、事前準備された情報のシグネチャに対して検証を実行し、事前準備された情報が第2のコンセンサスノードによって送信されたと決定することができる。さらに、検証は、前処理されたブロック中のサービスデータに基づいて、事前準備された情報のダイジェストに対して実行され、前処理されたブロックが、事前準備された情報のダイジェストに対応し決定される。さらに、事前準備された情報におけるnが所定のウォーターマーク(watermark)を満たすかどうかが決定され得、事前準備された情報におけるvが第1のコンセンサスノードの現在のvに一致するかどうかが決定され得る。

事前準備された情報がPBFT中に検証をパスしたと決定したコンセンサスノードが自動的に次の段階(すなわち、第2の段階)を実行するので、事前準備された情報が第2のアプリケーションによって実行された検証をパスした後に、第2のアプリケーションは、事前準備された情報と、前処理されたブロックと、受信された応答情報とを第1のデータベースに記憶し、準備された情報を検証結果として作成することができる。準備された情報のフォーマットは、<prepared, v, n, d, i>であり得、iは、準備された情報を作成するコンセンサスノードの識別子である。したがって、第2のアプリケーションは、準備された情報を第1のデータベースにさらに記憶し得る。

次いで、第2のアプリケーションは、コンセンサス検証を実行し続けるために、準備された情報を別のコンセンサスノードに送信し得る。さらに、事前準備された情報が検証をパスしたと決定した別のコンセンサスノードは、コンセンサスノードによって作成された、準備された情報に署名し、次いで、それをブロードキャストし得る。したがって、ブロックチェーンネットワーク中の各コンセンサスノードは、事前準備された情報が検証をパスしたと決定したコンセンサスノードによって送信された、準備された情報を受信することができ、各コンセンサスノードは、別のコンセンサスノードによって送信された、受信された準備された情報を、コンセンサスノードのデータベースに記憶することができる。

したがって、本出願の実装形態では、第1のコンセンサスノードの第1のアプリケーションは、別のコンセンサスノードによって送信された検証結果(すなわち、別のコンセンサスノードによって送信された、準備された情報)を再び受信し、検証結果を第1のデータベースに記憶し得る。第2のアプリケーションは、第1のデータベースに記憶された、準備された情報のv、n、シグネチャ、およびダイジェストに対して検証を実行し得る。第1のデータベースに記憶され、検証をパスした、準備された情報の量が所定の量よりも大きいかまたはそれに等しいと決定したとき、第2のアプリケーションは、次の段階(すなわち、第3の段階)を自動的に実行する。所定の量は、既存の技術におけるものと同じであり、PBFT計算を通してコンセンサスノードによって決定される。詳細は、本出願では省略される。

次いで、3段階プロトコルの第3の段階において、第3の段階が実行されるべきであると決定したとき、第2のアプリケーションは、適合情報(「コミット情報」)を作成し、コミット情報を別のコンセンサスノードに送信することができる。同様に、第3の段階が実行されるべきであると決定したとき、第2のコンセンサスノードの第3のアプリケーションまたは第4のアプリケーションもコミット情報を送信し得る。第1のアプリケーションは、別のコンセンサスノードによって送信されたコミット情報を受信し、コミット情報を第1のデータベースに記憶し得る。コミット情報のフォーマットは<commit, v, n, D, i>であり得、Dは、コンセンサスノードによって作成された、前処理されたブロックのダイジェストである。

最後に、第2のアプリケーションは、第1のデータベースに記憶され、別のコンセンサスノードによって送信されたコミット情報のv、n、シグネチャ、およびダイジェストに対して検証を実行することができ、検証をパスしたコミット情報の量が所定の量よりも大きいかまたはそれに等しいことが決定されたとき、前処理されたブロックがコンセンサス検証をパスしたことが決定される。

ブロックチェーンネットワーク中の各コンセンサスノードについて、3段階プロトコルの各段階において、別のコンセンサスノードから受信された情報、およびコンセンサスノードがコンセンサス検証を実行したときに生成された、作成された情報など、すべてのデータが、コンセンサスノードに対応するデータベースに記憶され得る。

確実に、本出願の実装形態において、第2のアプリケーションによって実行された、前に説明されたステップが、第1のアプリケーションによって実行され得、その逆も同様であることに留意することは、有益である。同様に、第3のアプリケーションによって実行されたすべてのステップは、第4のアプリケーションによっても実行され得、その逆も同様である。

さらに、3段階プロトコル実行プロセスにおいて、各コンセンサスノードは、別のコンセンサスノードに関する情報を送信および受信する必要があり、情報がネットワークを通して送られたとき、ネットワーク遅延が起こり得る。したがって、3段階プロトコルの各段階において、各コンセンサスノードは、情報を受信するための瞬間を待ち得る。したがって、3段階プロトコル実行プロセス中に、コンセンサスノードは、最初に、作成された情報と受信された情報とをデータベースに記憶し得る。さらに、各段階の待ち時間が終了したとき、データベースに記憶された情報に基づいて、次の段階を実行すべきかどうかが決定される。

さらに、本出願の実装形態では、3段階プロトコルの第1の段階(すなわち、事前準備段階)において、コンセンサス検証を開始する第2のコンセンサスノード(すなわち、1次ノード)は、前処理されたブロックと、前処理されたブロック中のサービスデータのハッシュ値とを第2のコンセンサスノードの各コンセンサスノードに送信することができる。さらに、事前準備された情報を受信した各コンセンサスノードは、サービスデータのハッシュ値に基づいて、前処理されたブロックを作成し、作成された前処理されたブロックと、1次ノードによって送信された、前処理されたブロックとに対して比較検証を実行し得る。

またさらに、本出願の実装形態では、各コンセンサスノードが、既存の技術におけるものと同じ、コンセンサス検証を実行するとき、コンセンサスノードは、コンセンサス条件に基づいて検証を実行し得る。言い換えれば、1次ノードによって送信されたサービスデータが、コンセンサス検証が実行され得るサービスデータであるかどうかが決定される。はいの場合、コンセンサスノードは、後続のコンセンサス検証を実行し続け、いいえの場合、コンセンサスノードは、コンセンサス検証を停止する。

図2に示されているブロックチェーンサービスコンセンサス方法に基づいて、第1のコンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、第1のデータベースとを含む。コンセンサスが実行されたとき、第1のアプリケーションは、コンセンサスデータを受信し、コンセンサスデータを第1のデータベースに記憶する。第2のアプリケーションは、第1のデータベースからコンセンサスデータをフェッチし、コンセンサス検証を実行し、第2のアプリケーションは、コンセンサスデータに検証結果を追加し、検証結果を第1のデータベースに記憶し、コンセンサス検証を実行し続けるために検証結果を別のコンセンサスノードに送信する。コンセンサス検証を開始する第2のコンセンサスノードの第3のアプリケーションは、第2のデータベースに記憶された送信済みサービスデータに基づいて、前処理されたブロックをコンセンサスデータとして作成し、コンセンサスデータを第2のデータベースに記憶し、第4のアプリケーションは、第2のデータベースからコンセンサスデータをフェッチし、コンセンサスデータを第2のコンセンサスノード以外のコンセンサスノードに送信する。本出願の実装形態では、コンセンサスノードが、コンセンサスに達するためにPBFTの3段階プロトコルを使用し、各段階において生成されたデータをデータベースに記憶して、コンセンサス検証中のキャッシュ占有率を低減し、キャッシュ利用を改善し得ることがわかり得る。したがって、コンセンサスノードのコンセンサス検証効率およびサービス要求処理効率が改善される。

本出願の実装形態において提供される方法のすべてのステップが同じデバイスによって実行され得るか、または、方法が異なるデバイスによって実行され得ることに留意することは、有益である。たとえば、ステップS201とステップS202とはデバイス1によって実行され得、ステップS203はデバイス2によって実行され得る。別の例では、ステップS201はデバイス1によって実行され得、ステップS202とステップS203とはデバイス2によって実行され得る。

図1に示されているブロックチェーンサービスハンドリング方法に基づいて、本出願の一実装形態は、対応して、図3に示されているように、ブロックチェーンサービスハンドリング装置をさらに提供する。

図3は、本出願の一実装形態による、ブロックチェーンサービスハンドリング装置を示す概略構造図である。コンセンサスノードが、本装置と、第2のアプリケーションと、データベースとを含む。本装置は、クライアントによって送信されたサービス要求を受信し、サービス要求に基づいて、対応する要送信サービスデータを決定するように構成された、受信モジュール301と、要送信サービスデータをデータベースに記憶するように構成された、記憶モジュール302とを含み、所定の条件が満たされたとき、第2のアプリケーションまたは送信モジュール303が、データベースから要送信サービスデータをフェッチし、要送信サービスデータを、記憶のために別のコンセンサスノードに送信する。

記憶モジュール302は、要送信サービスデータの状態が「要送信」状態であると決定し、サービスデータとサービスデータの対応する「要送信」状態とを記憶する。

指定された瞬間が来たとき、所定の条件が満たされたことが決定される。

送信モジュール303は、データベースから、指定された量の要送信サービスデータをフェッチする。

本装置は、データベース中の送信済みサービスデータの状態を「送信済み」状態に更新するように構成された、更新モジュール304をさらに含む。

詳細には、ブロックチェーンサービスハンドリング装置は、コンセンサスノード中にあり得る。コンセンサスノードは、エンドユーザデバイス、たとえば、モバイルフォン、タブレットコンピュータ、またはパーソナルコンピュータなどのデバイスであり得る。代替的に、コンセンサスノードは、サーバ、たとえば、別個のサーバ、または複数のサーバを含むシステムであり得る。

図2に示されているブロックチェーンサービスコンセンサス方法に基づいて、本出願の一実装形態は、対応して、図4に示されているように、ブロックチェーンサービスコンセンサス装置をさらに提供する。

図4は、本出願の一実装形態による、ブロックチェーンサービスコンセンサス装置を示す概略構造図である。コンセンサスノードが、第1のアプリケーションと、本装置と、第1のデータベースとを含み、本装置は、コンセンサスデータを受信し、コンセンサスデータを第1のデータベースに記憶するように構成された、受信モジュール401と、第1のデータベースからコンセンサスデータをフェッチし、コンセンサス検証を実行するように構成された、検証モジュール402と、コンセンサスデータに検証結果を追加し、検証結果を第1のデータベースに記憶し、コンセンサス検証を実行し続けるために検証結果を別のコンセンサスノードに送信するように構成された、記憶および送信モジュール403とを含む。

受信モジュール401は、別のコンセンサスノードによって送信されたコンセンサスデータを受信するか、または、別のコンセンサスノードによって送信された検証結果を受信し、検証結果をコンセンサスデータとして使用する。

検証モジュール402は、第1のデータベースからのコンセンサスデータ、および第1のデータベース中の「送信済み」状態にあるサービスデータをフェッチし、「送信済み」状態にあるサービスデータに基づいてコンセンサスデータに対してコンセンサス検証を実行し、検証結果を決定する。

第2のコンセンサスノードは、第3のアプリケーションと、第4のアプリケーションと、第2のデータベースとを含む。受信モジュール401がコンセンサスデータを受信する前に、第3のアプリケーションは、第2のデータベース中の「送信済み」状態にあるサービスデータに基づいてコンセンサスデータを決定し、コンセンサスデータを第2のデータベースに記憶し、第4のアプリケーションは、第2のデータベースからコンセンサスデータをフェッチし、コンセンサスデータを第2のコンセンサスノード以外のコンセンサスノードに送信する。

実用的ビザンチンフォールトトレランスPBFTアルゴリズムがコンセンサス検証のために使用される。

詳細には、図4に示されているブロックチェーンサービスハンドリング装置は、コンセンサスノード中にあり得る。コンセンサスノードは、エンドユーザデバイス、たとえば、モバイルフォン、タブレットコンピュータ、またはパーソナルコンピュータなどのデバイスであり得る。代替的に、コンセンサスノードは、サーバ、たとえば、別個のサーバ、または複数のサーバを含むシステムであり得る。

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

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

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

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

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

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

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

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

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

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

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

「含む(include)」、「備える、含む(comprise)」という用語、またはそれらの任意の他の変形態は非排他的包含をカバーするものとし、したがって、要素のリストを含むプロセス、方法、製品またはデバイスが、それらの要素を含むだけでなく、明確にリストされない他の要素をも含むか、あるいは、そのようなプロセス、方法、製品またはデバイスに固有の要素をさらに含むことにさらに留意することが、有益である。さらなる制約がなければ、「を含む(includes a ...)」の前にある要素は、その要素を含むプロセス、方法、製品またはデバイス中の追加の同等の要素の存在を妨げない。

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

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

本明細書における実装形態は、漸進的に説明される。実装形態の同じまたは同様の部分について、実装形態への参照が行われ得る。各実装形態は、他の実装形態との差異に焦点を当てる。詳細には、システム実装形態は、基本的に方法実装形態と同様であり、したがって、手短に説明される。関係する部分について、方法実装形態における関係する説明への参照が行われ得る。

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

301 受信モジュール
302 記憶モジュール
303 送信モジュール
304 更新モジュール
401 受信モジュール
402 検証モジュール
403 記憶および送信モジュール

Claims (20)

1. ブロックチェーンサービスハンドリング方法であって、コンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、データベースとを備え、前記方法が、
   前記第1のアプリケーションによって、クライアントによって送信されたサービス要求を受信するステップ、および前記サービス要求に基づいて、対応する要送信サービスデータを決定するステップと、
   前記第1のアプリケーションによって、前記要送信サービスデータを前記データベースに記憶するステップと、
   所定の条件が満たされたとき、前記第2のアプリケーションまたは前記第1のアプリケーションによって、前記データベースから前記要送信サービスデータをフェッチするステップ、および前記要送信サービスデータを、記憶のために別のコンセンサスノードに送信するステップとを含む、
   方法。
2. 前記第1のアプリケーションによって、前記要送信サービスデータを前記データベースに記憶するステップの前に、前記方法が、
   前記第1のアプリケーションによって、前記要送信サービスデータの状態が「要送信」状態であると決定するステップと、
   前記サービスデータと前記サービスデータの前記対応する「要送信」状態とを前記データベースに記憶するステップとをさらに含む、
   請求項1に記載の方法。
3. 所定の条件を前記満たすことが、詳細には、
   指定された瞬間が来たとき、前記所定の条件が満たされたと決定することを含む、
   請求項1に記載の方法。
4. 前記データベースから前記要送信サービスデータをフェッチするステップが、詳細には、
   前記データベースから、指定された量の要送信サービスデータをフェッチするステップを含む、
   請求項1に記載の方法。
5. 前記方法が、
   前記データベース中の送信済みサービスデータの状態を「送信済み」状態に更新するステップをさらに含む、
   請求項1に記載の方法。
6. ブロックチェーンサービスコンセンサス方法であって、第1のコンセンサスノードが、第1のアプリケーションと、第2のアプリケーションと、第1のデータベースとを備え、前記方法が、
   前記第1のアプリケーションによって、コンセンサスデータを受信するステップ、および前記コンセンサスデータを前記第1のデータベースに記憶するステップと、
   前記第2のアプリケーションによって、前記第1のデータベースから前記コンセンサスデータをフェッチするステップ、およびコンセンサス検証を実行するステップと、
   前記第2のアプリケーションによって、前記コンセンサスデータに検証結果を追加するステップ、前記検証結果を前記第1のデータベースに記憶するステップ、および前記コンセンサス検証を実行し続けるために前記検証結果を別のコンセンサスノードに送信するステップとを含む、
   方法。
7. 前記第1のアプリケーションによって、コンセンサスデータを受信するステップが、詳細には、
   前記第1のアプリケーションによって、別のコンセンサスノードによって送信されたコンセンサスデータを受信するステップ、または
   前記第1のアプリケーションによって、別のコンセンサスノードによって送信された検証結果を受信するステップ、および前記検証結果を前記コンセンサスデータとして使用するステップを含む、
   請求項6に記載の方法。
8. 前記第2のアプリケーションによって、前記第1のデータベースから前記コンセンサスデータをフェッチするステップ、およびコンセンサス検証を実行するステップが、詳細には、
   前記第2のアプリケーションによって、前記第1のデータベースからの前記コンセンサスデータ、および前記第1のデータベース中の「送信済み」状態にあるサービスデータをフェッチするステップと、
   前記「送信済み」状態にある前記サービスデータに基づいて前記コンセンサスデータに対してコンセンサス検証を実行するステップ、および検証結果を決定するステップとを含む、
   請求項6に記載の方法。
9. 第2のコンセンサスノードが、第3のアプリケーションと、第4のアプリケーションと、第2のデータベースとを備え、
   前記第1のアプリケーションによって、コンセンサスデータを受信するステップの前に、前記方法が、
   前記第3のアプリケーションによって、前記第2のデータベース中の「送信済み」状態にあるサービスデータに基づいて前記コンセンサスデータを決定するステップ、および前記コンセンサスデータを前記第2のデータベースに記憶するステップと、
   前記第4のアプリケーションによって、前記第2のデータベースから前記コンセンサスデータをフェッチするステップ、および前記コンセンサスデータを前記第2のコンセンサスノード以外のコンセンサスノードに送信するステップとをさらに含む、
   請求項6に記載の方法。
10. 実用的ビザンチンフォールトトレランス(PBFT)アルゴリズムが前記コンセンサス検証のために使用される、
    請求項6から9のいずれか一項に記載の方法。
11. ブロックチェーンサービスハンドリング装置であって、コンセンサスノードが、前記装置と、第2のアプリケーションと、データベースとを備え、前記装置が、
    クライアントによって送信されたサービス要求を受信し、前記サービス要求に基づいて、対応する要送信サービスデータを決定するように構成された、受信モジュールと、
    前記要送信サービスデータを前記データベースに記憶するように構成された、記憶モジュールとを備え、
    所定の条件が満たされたとき、前記第2のアプリケーションまたは送信モジュールが、前記データベースから前記要送信サービスデータをフェッチし、前記要送信サービスデータを、記憶のために別のコンセンサスノードに送信する、
    装置。
12. 前記記憶モジュールは、前記要送信サービスデータの状態が「要送信」状態であると決定し、前記サービスデータと前記サービスデータの前記対応する「要送信」状態とを記憶する、
    請求項11に記憶の装置。
13. 指定された瞬間が来たとき、前記所定の条件が満たされたことが決定される、
    請求項11に記載の装置。
14. 前記送信モジュールが、前記データベースから、指定された量の要送信サービスデータをフェッチする、
    請求項11に記載の装置。
15. 前記装置が、
    前記データベース中の送信済みサービスデータの状態を「送信済み」状態に更新するように構成された、更新モジュールをさらに備える、
    請求項11に記載の装置。
16. ブロックチェーンサービスコンセンサス装置であって、第1のコンセンサスノードが、第1のアプリケーションと、前記装置と、第1のデータベースとを備え、前記装置が、
    コンセンサスデータを受信し、前記コンセンサスデータを前記第1のデータベースに記憶するように構成された、受信モジュールと、
    前記第1のデータベースから前記コンセンサスデータをフェッチし、コンセンサス検証を実行するように構成された、検証モジュールと、
    前記コンセンサスデータに検証結果を追加し、前記検証結果を前記第1のデータベースに記憶し、前記コンセンサス検証を実行し続けるために前記検証結果を別のコンセンサスノードに送信するように構成された、記憶および送信モジュールとを備える、
    装置。
17. 前記受信モジュールが、別のコンセンサスノードによって送信されたコンセンサスデータを受信するか、または、別のコンセンサスノードによって送信された検証結果を受信し、前記検証結果を前記コンセンサスデータとして使用する、
    請求項16に記載の装置。
18. 前記検証モジュールが、前記第1のデータベースからの前記コンセンサスデータ、および前記第1のデータベース中の「送信済み」状態にあるサービスデータをフェッチし、前記「送信済み」状態にある前記サービスデータに基づいて前記コンセンサスデータに対してコンセンサス検証を実行し、検証結果を決定する、
    請求項16に記載の装置。
19. 第2のコンセンサスノードが、第3のアプリケーションと、第4のアプリケーションと、第2のデータベースとを備え、前記受信モジュールが前記コンセンサスデータを受信する前に、前記第3のアプリケーションが、前記第2のデータベース中の「送信済み」状態にあるサービスデータに基づいて前記コンセンサスデータを決定し、前記コンセンサスデータを前記第2のデータベースに記憶し、前記第4のアプリケーションが、前記第2のデータベースから前記コンセンサスデータをフェッチし、前記コンセンサスデータを前記第2のコンセンサスノード以外のコンセンサスノードに送信する、
    請求項16に記載の装置。
20. 実用的ビザンチンフォールトトレランス(PBFT)アルゴリズムが前記コンセンサス検証のために使用される、
    請求項16から19のいずれか一項に記載の装置。

Images