(57)【特許請求の範囲】
【請求項１】
ブロックチェーンを基にしたコンセンサスのための方法であって、前記方法が、
ブロックチェーンノードのデータベースにより、コンセンサス手順を実行するために必要なコンセンサスデータを記憶するステップであって、前記コンセンサスデータが、前記コンセンサス手順の間に、第1のサーバおよび第2のサーバによって呼び出され、前記ブロックチェーンノードが、ブロックチェーンに含まれ、前記第1のサーバ、前記第2のサーバ、および前記データベースを備える、ステップと、
前記第1のサーバの代わりに前記第2のサーバにより、前記コンセンサス手順に参加する別のデバイスによって送信されるコンセンサスメッセージを前記別のデバイスから受信するステップと、
前記第1のサーバに異常があるという判定に応答して、前記第1のサーバの代わりに前記第2のサーバにより、前記コンセンサスメッセージに基づいて前記データベースから前記コンセンサスメッセージに対応するコンセンサスデータを得るステップと、
前記コンセンサス手順の前に、または前記コンセンサス手順の間に前記第1のサーバに異常があるという判定に応答して、前記コンセンサスデータに基づいて前記コンセンサス手順を実行してコンセンサス結果を生成するステップと、
前記第2のサーバにより、前記コンセンサス結果を前記データベースに記憶するステップと、
を備える、ブロックチェーンを基にしたコンセンサス方法。
【請求項２】
前記コンセンサス手順の前に、または前記コンセンサス手順の間に前記第1のサーバに異常があると判定することが、前記第1のサーバが再起動されたと判定することを含む、請求項1に記載の方法。
【請求項３】
前記別のデバイスが、前記コンセンサスメッセージを送信するが、指定された時間の後に、応答を何も受信しないとき、前記別のデバイスが、前記コンセンサスメッセージの送信を再試行する、請求項1に記載の方法。
【請求項４】
前記コンセンサスメッセージが、サービス要求識別子を含む、請求項1に記載の方法。
【請求項５】
前記コンセンサスメッセージに基づいて前記データベースから前記コンセンサスメッセージに対応する前記コンセンサスデータを得るステップが、具体的に、
前記第2のサーバにより、前記コンセンサスメッセージに含まれる前記サービス要求識別子に基づいて、前記識別子に対応するコンセンサスデータについて前記データベースを検索し、前記識別子に対応するコンセンサスデータを得るステップを含む、請求項4に記載の方法。
【請求項６】
前記ブロックチェーンノードが、ゲートウェイをさらに備える、請求項1に記載の方法。
【請求項７】
前記コンセンサス手順に参加する別のデバイスによって送信される前記コンセンサスメッセージを受信するステップが、
前記ゲートウェイにより、前記コンセンサス手順の前に前記第1のサーバに異常があるという判定に応答して、前記コンセンサス手順に参加する前記別のデバイスによって送信される前記コンセンサスメッセージを、正常に動作する前記第2のサーバに転送するステップと、
前記第2のサーバにより、前記コンセンサス手順に参加する前記別のデバイスによって送信され、前記ゲートウェイによって転送される前記コンセンサスメッセージを受信するステップと、を備える、請求項6に記載の方法。
【請求項８】
前記コンセンサス手順に参加する別のデバイスが送信を再試行する前記コンセンサスメッセージを受信するステップが、
前記ゲートウェイにより、前記コンセンサス手順の間に前記第1のサーバに異常があるという判定に応答して、前記コンセンサス手順に参加する前記別のデバイスが送信を再試行する前記コンセンサスメッセージを、正常に動作する前記第2のサーバに転送するステップと、
前記第2のサーバにより、前記コンセンサス手順に参加する前記別のデバイスが送信を再試行し、前記ゲートウェイによって転送される前記コンセンサスメッセージを受信するステップと、を備える、請求項7に記載の方法。
【請求項９】
前記ゲートウェイが、前記第1のサーバの動作状況および前記第2のサーバの動作状況を、
前記ゲートウェイにより、所定の期間に基づいて前記第1のサーバおよび前記第2のサーバによって前記ゲートウェイに送信される動作状況メッセージを受信するステップと、
前記ゲートウェイにより、前記動作状況メッセージに基づいて前記第1のサーバの前記動作状況および前記第2のサーバの前記動作状況を判定するステップと、を備える動作を実行することによって判定する、請求項8に記載の方法。
【請求項１０】
前記ブロックチェーンが、コンソーシアムチェーンおよびプライベートチェーンの少なくとも1つを含む、請求項1に記載の方法。
【請求項１１】
ブロックチェーンを基にしたコンセンサスのためのデバイスであって、前記デバイスが、請求項1から10のいずれか一項に記載の方法を実行するように構成された複数のモジュールを備える、ブロックチェーンを基にしたコンセンサスのためのデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、コンピュータテクノロジの分野に関し、詳細には、ブロックチェーンを基にしたコンセンサス方法およびデバイスに関する。
【背景技術】
【０００２】
現在、ブロックチェーンテクノロジは、広く利用され、またその分散モードは、データが容易に不正変更されず、それによりセキュリティを改善することを確実にする。
【０００３】
実際の適用シナリオでは、ブロックチェーンは、対応するサービスをクライアントに提供することができ、ブロックチェーンノードは、ユーザのサービス要求を処理し、対応する処理結果を生成することができる。しかし、ブロックチェーンは、悪意のあるノードまたは異常のあるノードを含む恐れがある。それは、間違いなく、クライアントが得るサービスに影響を与える。したがって、例えば、実用ビザンチンフォールトトレランス(PBFT)を基にしたコンセンサス手順は、ブロックチェーン内のノードの間で実行でき、これにより、ノードは、正しい処理結果について合意することができる。
【０００４】
PBFTを基にしたコンセンサス手順を、例として使用する。図1に示すように、PBFTを基にしたコンセンサス手順は、事前準備(pre-prepare)段階、準備(prepare)段階、およびコミット(commit)段階を含む。サービス要求をクライアント(図1においてCによって表される)から受信するノード(図1において0と番号付けされるノード)は、コンセンサス手順を実行するために、サービス要求を他のノード(例えば、1、2、3と番号付けされるノード)に送信する。各段階において、ノードは、コンセンサスメッセージを互いに送信し、これにより、ノードは、コンセンサス手順を実行する。3段階のコンセンサス手順の後、コンセンサスが得られたと見なすことができる。この場合、ノードは、個別にサービス要求を処理し、それぞれ処理結果をクライアントにフィードバックする。
【０００５】
既存のテクノロジにおけるいくつかのシナリオでは、大量のコンセンサス手順を処理するために、複数のサーバが、通常、先に説明したブロックチェーン内の各ノードに配置され、また様々なサーバが、個別に様々なコンセンサス手順に参加して、ブロックチェーンの処理量および処理効率を改善することができる。
【０００６】
しかし、実際には、ノード内のサーバは、異常がある可能性、例えば、オフラインであるか再起動されている可能性がある。例えば、PBFTを基にしたコンセンサス手順では、サーバに異常があると、サーバは、コンセンサスへの参加を継続できず、コンセンサスを得る確率に影響を与える。コンセンサスが一定のラウンドにおいて得られない場合、コンセンサスは、現在ブロックチェーンが位置するコンセンサス段階にかかわらず、事前準備段階から再開始される必要がある。明らかであろうが、それは、間違いなく、ブロックチェーンのコンセンサス効率に影響を与え、さらに、ブロックチェーンのサービス処理効率に影響を与える。
【発明の概要】
【課題を解決するための手段】
【０００７】
本願の実装形態は、ノード内のサーバに異常があると、コンセンサス効率が相対的に低いという現在の問題を解決するために、ブロックチェーンを基にしたコンセンサス方法およびデバイスを提供する。
【０００８】
本願の実装形態は、ブロックチェーンを基にしたコンセンサス方法を提供する。1つのブロックチェーンノードは、第1のサーバ、第2のサーバ、および少なくとも1つのデータベースを備える。方法は、データベースにより、コンセンサス手順を実行するために必要なコンセンサスデータを記憶するステップであって、コンセンサスデータが、コンセンサス手順の間に、第1のサーバおよび第2のサーバによって呼び出される、ステップと、第1のサーバの代わりに前記第2のサーバにより、コンセンサスデータをデータベースから得、コンセンサス手順の前に、またはコンセンサス手順の間に第1のサーバに異常があるという判定に応答して、コンセンサスデータに基づいてコンセンサス手順を実行してコンセンサス結果を生成するステップと、第2のサーバにより、コンセンサス結果をデータベースに記憶するステップと、を含む。
【０００９】
本願の実装形態は、ブロックチェーンを基にしたコンセンサスデバイスを提供し、1つのブロックチェーンノードが、第1のサーバ、第2のサーバ、および少なくとも1つのデータベースを備え、データベースが、コンセンサス手順を実行するために必要なコンセンサスデータを記憶し、コンセンサスデータが、コンセンサス手順の間に、第1のサーバおよび第2のサーバによって呼び出され、第1のサーバに、コンセンサス手順の前に、またはコンセンサス手順の間に異常があり、デバイスが、コンセンサスメッセージに対応するコンセンサスデータを、データベースから、コンセンサスメッセージに基づいて得るように構成された取得モジュールと、コンセンサスデータに基づいてコンセンサス手順を実行してコンセンサス結果を生成するように構成されたコンセンサス実行モジュールと、コンセンサスメッセージおよびコンセンサス結果をデータベースに記憶するように構成された記憶モジュールとを備える。
【００１０】
本願の実装形態において提供されるブロックチェーンを基にしたコンセンサス方法およびデバイスによれば、ブロックチェーンノード内の各サーバのために、一定のコンセンサス手順に参加するサーバは、様々なコンセンサス段階におけるコンセンサスメッセージ、またはサーバが生成する現段階におけるコンセンサス結果を「パブリックに」記憶する。すなわち、サーバは、ブロックチェーンノード内のデータベースに、様々なコンセンサス段階におけるコンセンサスメッセージ、またはサーバが生成する現段階におけるコンセンサス結果を記憶し、データベースは、ブロックチェーンノード内のすべてのサーバのために使用可能である。したがって、一定のラウンドのコンセンサスに参加するサーバが、異常がある、例えば、オフラインであるか再起動されている場合、サーバのコンセンサスデータは、ブロックチェーンノード内の別のサーバによって使用することができ、別のサーバが、異常のあるサーバの代わりに、対応するコンセンサス手順の実行を継続することができる。
【００１１】
明らかであろうが、既存のテクノロジに比べて、ブロックチェーンノード内の各サーバがコンセンサスデータをブロックチェーンノード内のデータベースに記憶する方法では、あるサーバに異常があるときでさえ、正常に動作するサーバが、異常のあるサーバの代わりに、対応するコンセンサスデータをデータベースから得てコンセンサスを完了することができる。これによってコンセンサス手順の正常な実行を確保できるため、コンセンサス手順の成功率を一定程度改善することができ、一方コンセンサス再開始の回数が減少し、その結果、ブロックチェーンのサービス処理効率を改善する。
【００１２】
ここで説明する添付図面は、本願のさらなる理解の実現を意図するものであり、本願の一部を構成する。本願の例示的実装形態およびその説明は、本願の説明を意図するものであり、本願を限定するものとはならない。添付図面は、以下のとおりである。
【図面の簡単な説明】
【００１３】
【図１】既存のテクノロジにおけるPBFTを基にしたコンセンサス手順を示す図である。
【図２ａ】本願の実装形態による、ブロックチェーンを基にしたコンセンサス手順における、ブロックチェーンのアーキテクチャを示す図である。
【図２ｂ】本願の実装形態による、ブロックチェーンを基にしたコンセンサス手順における、ブロックチェーンノードのアーキテクチャを示す図である。
【図２ｃ】本願の実装形態による、サーバ側における、ブロックチェーンを基にしたコンセンサス手順を示す図である。
【図２ｄ】本願の実装形態による、別のタイプのブロックチェーンノードのアーキテクチャを示す図である。
【図３ａ】本願の実装形態による、図3bと同じコンセンサス手順におけるサーバ変更プロセスを示す概略図である。
【図３ｂ】本願の実装形態による、図3aと同じコンセンサス手順におけるサーバ変更プロセスを示す概略図である。
【図４】本願の実装形態による、サーバ側における、ブロックチェーンを基にしたコンセンサスデバイスを示す概略構造図である。
【発明を実施するための形態】
【００１４】
本願の目的、技術的な解決策、および利点をより明確にするために、以下は、本願の技術的な解決策について、本願の特定の実装形態および対応する添付図面を参照して明確で包括的に説明する。明らかであろうが、説明される実装形態は、本願の実装形態の単にいくつかであってすべてではない。当業者が本願の実装形態に基づいて、創造的な努力をすることなく得る他のすべての実装形態は、本願の保護範囲に含まれるものとする。
【００１５】
上述のように、ブロックチェーン内のノード間で実行される任意のコンセンサス時間の間に、任意のノードにおいて現在のコンセンサス時間に参加するサーバは、異常がある可能性、例えば、オフラインであるか再起動されている可能性があり、その結果としてサーバは、コンセンサスへの参加を継続できない。したがって、コンセンサスの成功率が低下する恐れがある。具体的には、PBFTを基にしたコンセンサスの場合、コンセンサスの一定数の失敗は、各サーバ内のコンセンサスデータをクリーンな状態にするために、PBFT下で不要データ収集メカニズムを起動する恐れがある。明らかであろうが、それは、間違いなく、ブロックチェーンのサービス処理に影響を与える。
【００１６】
先の説明に従って、本願の実装形態は、ブロックチェーンを基にしたコンセンサス方法を提供する。方法では、コンセンサスデータは、ブロックチェーンノード内のデータベース内に記憶され、これにより、サーバに異常がある(サーバがオフラインであるか再起動されている)と、ブロックチェーンノード内の正常に動作するサーバが同様に、異常のあるサーバの代わりに、データベース内に記憶されたコンセンサスデータを読み取り、コンセンサス手順の実行を継続することができる。もちろん、本願の実装形態におけるブロックチェーンを基にしたコンセンサス方法は、PBFTを基にしたコンセンサス手順のみに限定されるものではなく、Paxosなどのコンセンサスアルゴリズムに基づくコンセンサス手順においてもさらに使用することができる。
【００１７】
本願の実装形態においては、ブロックチェーンを基にしたコンセンサス方法において使用されるアーキテクチャを図2aに示すことに留意されたい。図2aから、ブロックチェーンが複数のブロックチェーンノードを備えることを理解することができる。後の説明の簡略化のために、ブロックチェーンノードは、以下、簡潔にノードと呼ぶ。
【００１８】
複数のクライアントが、ブロックチェーンとサービス上の対話を実行することができる。ブロックチェーンは、コンソーシアムチェーンおよび/またはプライベートチェーンであり得、サービスをユーザに提供することができる。クライアントは、ブラウザ、アプリケーションなどを備えてもよい。クライアントは、端末、サーバ、データベースなどにおいて動作可能である。実装形態は、ここでは特に限定されるものではない。
【００１９】
図2aに示すアーキテクチャに基づいて、任意のノードのアーキテクチャを図2bに示すことができる。図2bから、ノードがn台のサーバ、およびサーバによって共有される1つのデータベースを備えることを理解することができる。様々なサーバが、様々なコンセンサス手順に参加することができ、サーバは、互いに独立して動作可能である。データベースは、データ記憶サービスを、ノード内のサーバに提供するように構成される。すなわち、各サーバは、コンセンサス手順において、対応するコンセンサスデータをデータベースに記憶することができる。もちろん、図2bに示すノード内のデータベースの数は、単によく用いられる数である。実際には、ノード内のデータベースの数は、実際の需要に基づいて、調整することができる。さらに、いくつかのシナリオでは、ノード内のサーバは、コンピュータなどの、コンピューティング処理機能を有するデバイスと置き換えることができる。
【００２０】
さらに、説明の簡略化のために、以下では、動作中に異常を伴う可能性があるサーバを第1のサーバと呼び、正常に動作可能であるサーバを第2のサーバと呼ぶことに留意されたい。したがって、図2bに示すアーキテクチャにおいて、アーキテクチャは、第1のサーバと第2のサーバという2種類のサーバを含むと見なすことができる。先の内容は、本願を限定するものと見なされるべきではない。
【００２１】
図2bに示す関係アーキテクチャに基づいて、本願の実装形態は、ブロックチェーンを基にしたコンセンサス手順を提供する。図2cに示すように、手順は、具体的には、以下のステップを含む。
【００２２】
S201。データベースが、コンセンサス手順を実行するために必要なコンセンサスデータを記憶し、コンセンサスデータが、コンセンサス手順の間に、第1のサーバおよび第2のサーバによって呼び出される。
【００２３】
図2bのアーキテクチャに基づいて、データベースは、内部にサーバが設置されたノード内に配置され、ノード内のすべてのサーバによって共有される。コンセンサスメッセージを受信するか、コンセンサス結果を生成した後、ノード内の任意のサーバが、コンセンサスメッセージまたはコンセンサス結果をデータベースに記憶する。次いで、サーバは、データベースから、コンセンサス手順を実行するために必要なコンセンサスデータを得ることができる。コンセンサスデータには、サーバによって別のノード内のサーバから受信されるコンセンサスメッセージ、そのサーバによって生成されるコンセンサス結果、クライアントによって送信され、コンセンサス手順を起動することができるサービス要求などが含まれてもよい。
【００２４】
ここでは、コンセンサスデータをデータベースに記憶することは、コンセンサスデータがノード内のすべてのサーバに利用可能であるようにすることに留意されたい。すなわち、第1のサーバに異常がある場合、第1のサーバは、コンセンサスへの参加を継続できないが、ノード内の第2のサーバは、異常のあるサーバの代わりに、データベース内に記憶されたコンセンサスデータに基づいて、コンセンサスを実行することができる。
【００２５】
S202。第2のサーバが、コンセンサス手順の前に、またはコンセンサス手順の間に第1のサーバに異常があるという判定に応答して、第1のサーバの代わりに、コンセンサスデータをデータベースから得て、コンセンサスデータに基づいてコンセンサス手順を実行してコンセンサス結果を生成する。
【００２６】
実際の実行中、コンセンサスに参加する第1のサーバは、異常がある(例えば、故障しているか再起動されている)可能性があり、障害が不規則に起きる恐れもあるが、コンセンサス手順の実装形態は、第1のサーバの異常がコンセンサス手順の前にあるか、コンセンサス手順の間にあるかにかかわらず、影響を受ける。この場合、コンセンサス手順が影響を受けないようにするため、ブロックチェーンノード内の正常に動作する第2のサーバは、異常がある第1のサーバの代わりに、コンセンサスを実行することができる。
【００２７】
第1のサーバに異常があると、コンセンサスの実行を継続できない。したがって、第2のサーバは、コンセンサスメッセージを第1のサーバの代わりに受信し、第1のサーバが元々は参加しているコンセンサス手順に参加することができる。
【００２８】
上述のように、ノード内の任意のサーバは、コンセンサスデータをデータベースに記憶し、これにより、第2のサーバは、コンセンサス手順に必要なコンセンサスデータについてデータベースを検索し、そのコンセンサスデータを得ることができ、異常がある第1のサーバの代わりにコンセンサスを実行し、さらに、対応するコンセンサス結果を生成する。
【００２９】
明らかであろうが、正常に動作するサーバは、異常のあるサーバの代わりにコンセンサスを実行し、これにより、コンセンサス手順が影響を受けないことを確実にする。
【００３０】
S203。第2のサーバが、コンセンサス結果をデータベースに記憶する。
【００３１】
本願の本実装形態では、第1のサーバの代わりにコンセンサスを実行する第2のサーバはまた、コンセンサス結果を、コンセンサスデータの一種として、本願におけるデータ記憶メカニズムに基づいて、データベースに記憶する。
【００３２】
先のステップによれば、ブロックチェーンノード内の各サーバのために、一定のコンセンサス手順に参加するサーバは、様々なコンセンサス段階におけるコンセンサスメッセージ、またはサーバが生成する現段階におけるコンセンサス結果を「パブリックに」記憶する。すなわち、サーバは、ブロックチェーンノード内のデータベースに、様々なコンセンサス段階におけるコンセンサスメッセージ、またはサーバが生成する現段階におけるコンセンサス結果を記憶し、データベースは、ブロックチェーンノード内のすべてのサーバのために使用可能である。したがって、一定のラウンドのコンセンサスに参加するサーバが、異常がある、例えば、オフラインであるか再起動されている場合、サーバのコンセンサスデータは、ブロックチェーンノード内の別のサーバによって使用することができ、別のサーバが、異常のあるサーバの代わりに、対応するコンセンサス手順の実行を継続することができる。
【００３３】
明らかであろうが、既存のテクノロジに比べて、ノード内の各サーバがコンセンサスデータをノード内のデータベースに記憶する方法では、あるサーバに異常があるときでさえ、正常に動作するサーバが、異常のあるサーバの代わりに、対応するコンセンサスデータをデータベースから得てコンセンサスを完了することができる。これによってコンセンサス手順の正常な実行を確保できるため、コンセンサス手順の成功率を一定程度改善することができ、一方コンセンサス再開始の回数が減少し、その結果、ブロックチェーンのサービス処理効率を改善する。
【００３４】
ここでは、コンセンサス手順の間に、ノード内の任意のサーバは、同じコンセンサス手順に参加する別のデバイスによって送信されるコンセンサスメッセージを受信することに留意されたい。別のデバイスには、コンセンサス手順に参加する別のノードおよび/またはクライアントが含まれるが、それに限定されるものではない。コンセンサスメッセージは、クライアントによって送信され、コンセンサスを起動することができるサービス要求を含んでもよく、またコンセンサス手順において別のノードによって送信されるコンセンサスデータを含んでもよい。
【００３５】
明らかであろうが、一定のコンセンサス手順の場合、第1のサーバに異常がある場合、第2のサーバが、コンセンサスメッセージを、第1のサーバの代わりに受信して、第1のサーバのコンセンサス手順に参加する。
【００３６】
したがって、コンセンサス手順の前に第1のサーバに異常があるという判定に応答して、第2のサーバが、第1のサーバの代わりに、コンセンサスデータをデータベースから得ることは、第1のサーバの代わりに第2のサーバにより、コンセンサス手順に参加する別のデバイスによって送信されるコンセンサスメッセージを受信することと、コンセンサス手順の前に第1のサーバに異常があるという判定に応答して、コンセンサスメッセージに対応するコンセンサスデータを、データベースから、コンセンサスメッセージに基づいて得ることと、を含むことができる。
【００３７】
さらに、本願の本実装形態には、再試行メカニズムがある。具体的には、コンセンサス手順に参加する別のデバイスが、一定のコンセンサスメッセージまたはサービス要求を送信した後、別のデバイスが、ピアエンドから指定された時間内に応答を何も受信しない場合、別のデバイスが、同じコンセンサスメッセージまたはサービス要求を再送信する。コンセンサス手順の間に第1のサーバに異常がある場合、第1のサーバは、指定された時間に、別のデバイスに応答できないことがわかる。
【００３８】
したがって、コンセンサス手順の間に第1のサーバに異常があるという判定に応答して、第2のサーバが、第1のサーバの代わりに、コンセンサス手順に参加する別のデバイスが送信を再試行するコンセンサスメッセージを受信し、またコンセンサスメッセージに対応するコンセンサスデータを、データベースから、コンセンサスメッセージに基づいて得る。
【００３９】
第2のサーバは、通常、コンセンサスデータを、データベースから、コンセンサスメッセージ内の対応する識別子に基づいて得る。以下、コンセンサスデータをデータベースから得るプロセスを説明する。
【００４０】
PBFTを基にしたコンセンサス手順の間に、1つのサービス要求が、1つのコンセンサス手順に対応し、サービス要求をクライアントから受信するノード(マスタノードとも呼ばれる)が、サービス要求に番号付けする(例えば、索引付けする)。すなわち、サービス要求に関連付けられた番号は、1つのコンセンサス手順に一意に対応し得る。
【００４１】
具体的には、ノード内の任意のサーバが参加する一定のコンセンサス手順において、コンセンサス手順内のサービス要求の番号(すなわち、サービス要求識別子)は、1つのコンセンサス手順を一意に識別することができる。サービス要求に関連付けられた番号は、コンセンサス手順を、ノード内の別のサーバが参加するコンセンサス手順から区別するために使用することができる。したがって、サーバが、一定のサービス要求に関連付けられた番号を伝送するコンセンサスメッセージを受信した場合、サーバは、同じサービス要求番号を有するコンセンサスデータ(獲得されるコンセンサスデータおよびコンセンサスメッセージは、同じコンセンサス手順に属する)を、データベースから、サービス要求番号に基づいて得ることができる。
【００４２】
例えば、コンセンサス手順において、コンセンサスメッセージのフォーマットは、<コンセンサス段階識別子,ビュー番号(view number),サービス要求番号,サービス要求ダイジェスト(service request digest)>であり得る。サーバが、一定のコンセンサスメッセージ<commit, v, n, D(m)>を受信すると仮定され、ここで、commitは、ノードがコミット段階に入ったことを示し、vは、ビュー番号を示し、nは、サービス要求に関連付けられた番号を示し、D(m)は、通知メッセージを送信するノードの、サービス要求に対する署名を示す。この場合、サーバは、番号「n」に基づいて、番号「n」に対応するすべてのコンセンサスデータについてデータベースを検索することができる。
【００４３】
先の説明に従って、第2のサーバにより、データベースから、コンセンサスメッセージに対応するコンセンサスデータを得るプロセスは、次のとおりである。第2のサーバは、コンセンサスメッセージに含まれるサービス要求識別子に基づいて、識別子に対応するコンセンサスデータについてデータベースを検索し、識別子に対応するコンセンサスデータを得る。
【００４４】
先の内容に加えて、実際には、コンセンサスメッセージが異常がある第1のサーバに送信されるのを防止するために、本願の本実装形態では、コンセンサスメッセージを、ノード内のゲートウェイを使用することによってスケジュールすることができる。すなわち、ブロックチェーンノードは、ゲートウェイをさらに備える。この場合、ノードのアーキテクチャは、図2dに示すことができる。ゲートウェイは、ノード内のサーバへのコンセンサスメッセージをスケジュールする責任を負うことがわかる。第1のサーバに異常があると、ゲートウェイは、コンセンサスメッセージを異常がある第1のサーバに送信せず、代わりにコンセンサスメッセージを正常に動作する第2のサーバに送信する。
【００４５】
したがって、具体的には、第2のサーバの場合、コンセンサスメッセージを受信するプロセスは、次のとおりであり得る。
【００４６】
ゲートウェイが、コンセンサス手順の前に第1のサーバに異常があると判定すると、ゲートウェイは、コンセンサス手順に参加する別のデバイスによって送信される受信したコンセンサスメッセージを正常に動作する第2のサーバに転送する。この場合、第2のサーバは、コンセンサス手順に参加する別のデバイスによって送信され、またゲートウェイによって転送されるコンセンサスメッセージを受信する。
【００４７】
さらに、ゲートウェイが、コンセンサス手順の間に第1のサーバに異常があると判定すると、ゲートウェイは、コンセンサス手順に参加する別のデバイスが送信を再試行する受信したコンセンサスメッセージを正常に動作する第2のサーバに転送する。それに対応して、第2のサーバは、コンセンサス手順に参加する別のデバイスが送信を再試行し、またゲートウェイによって転送されるコンセンサスメッセージを受信する。
【００４８】
本願の本実装形態では、ゲートウェイが、コンセンサスメッセージをノード内の正常な第2のサーバに転送すると理解することができる。すなわち、ゲートウェイは、異常のあるサーバおよびノード内で正常に動作し続けているサーバを知る必要がある。
【００４９】
本願の本実装形態では、ノード内の各サーバは、ハートビート機構を使用することによってゲートウェイと通信することができ、これにより、ゲートウェイは、各サーバの動作状況を知ることができる。すなわち、ゲートウェイは、第1のサーバの動作状況および第2のサーバの動作状況を、以下の方法で、すなわち、ゲートウェイにより、所定の期間に基づいて第1のサーバおよび第2のサーバによってゲートウェイに送信される動作状況メッセージを受信することと、ゲートウェイにより、動作状況メッセージに基づいて第1のサーバの動作状況および第2のサーバの動作状況を判定することとで判定する。
【００５０】
すなわち、ゲートウェイが周期的な動作状況メッセージを受信できる場合、ゲートウェイは、動作状況メッセージを送信するサーバが正常に動作していると判定することができ、またゲートウェイが、動作状況メッセージを一定のサーバから一定の時間内、何も受信しない場合、ゲートウェイは、サーバに異常があると判定することができる。
【００５１】
以下、適用例を説明に使用する。
【００５２】
例えば、図3aに示すように、ノード1内のサーバ11とノード2内のサーバ21の両方が一定のコンセンサス手順に参加すると仮定される(図3aは、グレーで、2つのサーバが同じコンセンサス手順に従うことを示す)。さらに、サーバ21はオフラインである(すなわち、ノード2において、サーバ21は第1のサーバである)と仮定される。この事例では、サーバ11は、一定のコンセンサスメッセージをサーバ21に送信する。明らかであろうが、サーバ21はオフラインなので、サーバ21は、どんなフィードバックも提供しない。この事例では、特定の期間待った後、サーバ11は、再試行(再試行は、ノード1によって開始される再試行と見なすこともできる)を開始する、すなわち、コンセンサスメッセージを再送信する。ノード2内のゲートウェイが、ノード1が送信を再試行するコンセンサスメッセージを受信した後、ゲートウェイは、ノード1の再試行を処理するために、ノード2内で正常に動作する一定のサーバを選択する。図3bに示すように、この例では、ノード2内のサーバ22が選択される(すなわち、サーバ22は、第2のサーバである)。すなわち、ゲートウェイは、サーバ22に、ノード1が送信を再試行するコンセンサスメッセージを転送し、サーバ22は、サーバ21の代わりにコンセンサス手順を実行する。
【００５３】
さらに、第2のサーバにより、コンセンサスデータをサーバに記憶するプロセスの場合、本願の本実装形態における方法では、第2のサーバは、コンセンサスメッセージを受信した後、即座に、受信したコンセンサスメッセージ(コンセンサスメッセージは、コンセンサスデータの一種と見なすことができる)をデータベースに記憶し、またコンセンサス結果をコンセンサス手順を通じて生成した後、コンセンサスメッセージに対応するコンセンサス結果(コンセンサス結果も、コンセンサスデータの一種と見なすことができる)をデータベースに記憶することができる。
【００５４】
さらに、本願の本実装形態における別の方法では、コンセンサスメッセージを受信した後、第2のサーバは、前述のプロセスを通じて生成するコンセンサス結果を待ち、次いで、コンセンサスメッセージを、コンセンサス結果と共にデータベースに記憶する。
【００５５】
先の2つの記憶方法は、本願を限定するものとはならない。
【００５６】
本願の実装形態において提供される、ブロックチェーンを基にしたコンセンサス方法が、上述されている。同じ概念に基づいて、図4に示すように、本願の実装形態は、ブロックチェーンを基にしたコンセンサスデバイスをさらに提供する。1つのブロックチェーンノードは、複数のサーバおよび少なくとも1つのデータベースを備える。データベースは、コンセンサス手順を実行するために必要なコンセンサスデータを記憶し、コンセンサスデータが、コンセンサス手順の間に、第1のサーバおよび第2のサーバによって呼び出される。
【００５７】
第1のサーバに、コンセンサス手順の前に、またはコンセンサス手順の間に異常がある。
【００５８】
ブロックチェーンを基にしたコンセンサスデバイスは、少なくとも受信モジュール401、取得モジュール402、コンセンサス実行モジュール403、および記憶モジュール404を備える。
【００５９】
取得モジュール402は、コンセンサスデータをデータベースから得るように構成される。
【００６０】
コンセンサス実行モジュール403は、コンセンサスデータに基づいてコンセンサス手順を実行してコンセンサス結果を生成するように構成される。
【００６１】
記憶モジュール404は、コンセンサス結果をデータベースに記憶するように構成される。
【００６２】
受信モジュール401は、コンセンサス手順に参加する別のデバイスによって送信されるコンセンサスメッセージを受信するように構成され、取得モジュールが、コンセンサス手順の前に第1のサーバに異常があるという判定に応答して、コンセンサスメッセージに対応するコンセンサスデータを、データベースから、コンセンサスメッセージに基づいて得るように構成される。
【００６３】
受信モジュール401は、コンセンサス手順に参加する別のデバイスが送信を再試行するコンセンサスメッセージを受信するように構成され、取得モジュールが、コンセンサス手順の間に第1のサーバに異常があるという判定に応答して、コンセンサスメッセージに対応するコンセンサスデータを、データベースから、コンセンサスメッセージに基づいて得るように構成される。
【００６４】
別のデバイスが、コンセンサスメッセージを送信するが、指定された時間の後に、応答を何も受信しないとき、別のデバイスは、コンセンサスメッセージの送信を再試行する。
【００６５】
コンセンサスメッセージは、サービス要求識別子を含む。取得モジュール402は、コンセンサスメッセージに含まれるサービス要求識別子に基づいて、識別子に対応するコンセンサスデータについてデータベースを検索し、識別子に対応するコンセンサスデータを得るように構成される。
【００６６】
さらに、ブロックチェーンノードは、ゲートウェイをさらに備えることができる。この場合、デバイスは、少なくともゲートウェイ受信モジュール405、動作状況判定モジュール406、および転送モジュール407をさらに備える。
【００６７】
動作状況判定モジュール406が、コンセンサス手順の前に第1のサーバに異常があると判定すると、転送モジュール407は、正常に動作する第2のサーバに、コンセンサス手順に参加する別のデバイスによって送信される受信したコンセンサスメッセージを転送するように構成される。
【００６８】
動作状況判定モジュール406が、コンセンサス手順の間に第1のサーバに異常があると判定すると、転送モジュール407は、コンセンサス手順に参加する別のデバイスが送信を再試行する受信したコンセンサスメッセージを正常に動作する第2のサーバに転送するように構成される。
【００６９】
ゲートウェイ受信モジュール405は、所定の期間に基づいて第1のサーバおよび第2のサーバによってゲートウェイに送信される動作状況メッセージを受信するように構成される。
【００７０】
動作状況判定モジュール406は、第1のサーバの動作状況および第2のサーバの動作状況を動作状況メッセージに基づいて判定するように構成される。
【００７１】
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)および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)、もしくは別の光学式ストレージ、磁気カセット、磁気テープ、磁気ディスクメモリ、もしくは別の磁気記憶デバイス、またはコンピューティングデバイスがアクセスできる情報を記憶するために使用できる任意の他の非伝送媒体が含まれるが、それに限定されるものではない。本明細書における定義に基づいて、コンピュータ可読媒体には、変調データ信号や搬送波などの一時的コンピュータ可読媒体(一時的媒体)は含まれない。
【００８２】
「備える、含む(comprise)」、「備える、含む(include)」という語、または他の、その変化形は、要素のリストを含むプロセス、方法、製品、またはデバイスが、それらの要素だけを含むのではなく、明示的にリストされていない他の要素も含み、またはそうしたプロセス、方法、製品、またはデバイスに固有でない要素をさらに含むように、非排他的な包含をカバーするものであることにさらに留意されたい。さらなる制約なく、「備える、含む(includes a …)」が先行する要素は、要素を含むプロセス、方法、製品、またはデバイスにおいて追加の同一の要素の存在を排除しない。
【００８３】
本願の実装形態は、方法、システム、またはコンピュータプログラム製品として提供できることを当業者なら理解するであろう。したがって、本願は、ハードウェアだけの実装形態、ソフトウェアだけの実装形態、またはソフトウェアとハードウェアを組み合わせた実装形態の形を使用することができる。さらに、本願は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(それだけに限定されるものではないが、磁気ディスクストレージ、CD-ROM、光メモリなど)上に実装されるコンピュータプログラム製品の形を使用することができる。
【００８４】
本願は、コンピュータによって実行されるコンピュータ実行可能命令、例えば、プログラムモジュールの一般的な文脈の中で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、特定の抽象データ型を実行するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本願は、代替方法として、分散コンピューティング環境で実施することができる。こうした分散コンピューティング環境では、タスクは、通信ネットワークを介して接続されるリモート処理デバイスによって実行される。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方の、記憶デバイスを含む、コンピュータ記憶媒体に配置することができる。
【００８５】
本明細書における実装形態は、漸進的に説明されている。実装形態の同一または類似の部分については、実装形態を相互に参照することができる。各実装形態は、他の実装形態との違いに焦点を合わせている。特に、システムの実装形態は、基本的に方法の実装形態に類似しており、したがって簡潔に説明される。関連する部分については、方法の実装形態のいくつかの説明を参照することができる。
【００８６】
先の説明は、単に本願の実装形態であり、本願を限定することは意図されない。当業者であれば、本願に様々な修正および変更を加えることができる。本願の趣旨および原理から逸脱することなく実施される、任意の修正、同等な置換え、改善などは、本願の請求項の範囲に含まれるものとする。
【符号の説明】
【００８７】
1  ノード
2  ノード
11  サーバ
12  サーバ
21  サーバ
22  サーバ
401  受信モジュール
402  取得モジュール
403  コンセンサス実行モジュール
404  記憶モジュール
405  ゲートウェイ受信モジュール
406  動作状況判定モジュール
407  転送モジュール
【図１】
0006756924.tif 000002
【図２ａ】
0006756924.tif 000003
【図２ｂ】
0006756924.tif 000004
【図２ｃ】
0006756924.tif 000005
【図２ｄ】
0006756924.tif 000006
【図３ａ】
0006756924.tif 000007
【図３ｂ】
0006756924.tif 000008
【図４】
0006756924.tif 000009