特許 6773912 サービス処理およびコンセンサスの方法およびデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6773912

(24)【登録日】2020年10月5日

(45)【発行日】2020年10月21日

(54)【発明の名称】サービス処理およびコンセンサスの方法およびデバイス

(51)【国際特許分類】

   H04L 9/32 20060101AFI20201012BHJP

   G09C 1/00 20060101ALI20201012BHJP

   G06F 21/62 20130101ALI20201012BHJP

【ＦＩ】

   H04L9/00 675Z

   G09C1/00 640D

   G06F21/62 318

【請求項の数】20

【全頁数】31

(21)【出願番号】特願2019-535947(P2019-535947)

(86)(22)【出願日】2018年3月26日

(65)【公表番号】特表2020-508594(P2020-508594A)

(43)【公表日】2020年3月19日

(86)【国際出願番号】CN2018080461

(87)【国際公開番号】WO2018177239

(87)【国際公開日】20181004

【審査請求日】2019年8月26日

(31)【優先権主張番号】201710191462.X

(32)【優先日】2017年3月28日

(33)【優先権主張国】CN

【早期審査対象出願】

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(74)【代理人】

【識別番号】100205785

【弁理士】

【氏名又は名称】▲高▼橋 史生

(72)【発明者】

【氏名】イ・リ

【審査官】 吉田 歩

(56)【参考文献】

【文献】 米国特許出願公開第２０１７／００４６６８０（ＵＳ，Ａ１）

【文献】 中国特許出願公開第１０６０２２６８１（ＣＮ，Ａ）

【文献】 大藏 善樹 ほか，コミュニティネットワークにおけるＰｕｓｈ型Ｐ２Ｐを用いた耐障害性ネットワーク，電子情報通信学会技術研究報告，社団法人電子情報通信学会，Ｖｏｌ．１０７，Ｎｏ．５２５，ｐｐ．３７９−３８４

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／６２

Ｇ０９Ｃ １／００

(57)【特許請求の範囲】

【請求項1】

サービス処理のためのコンピュータ実施方法であって、
コンセンサスネットワーク内の第1のブロックチェーンノードの第1のサーバによって、クライアントによって送信されたサービスリクエストを受信するステップであって、前記コンセンサスネットワークは、複数の追加のブロックチェーンノードをさらに含み、前記コンセンサスネットワークの前記第1のブロックチェーンノードおよび前記複数の追加のブロックチェーンノードの各ノードは、対応する複数のサーバを含む、ステップと、
前記第1のブロックチェーンノードの少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップと、
前記第1のブロックチェーンノードによって、登録センタから、前記コンセンサスネットワーク内の前記複数の追加のブロックチェーンノードの各ノードについての前記対応する複数のサーバの各サーバのアドレスを取得するステップと、
前記取得したアドレスに基づいて前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記サービスリクエストを送信するステップであって、追加のブロックチェーンノードの各々は、前記サービスリクエストを受信した後に対応する少なくとも1つのサービスメモリに前記サービスリクエストを記憶する、ステップと
を含む、コンピュータ実施方法。

【請求項2】

前記第1のブロックチェーンノードの前記第1のサーバから、前記第1のブロックチェーンノードの複数の追加のサーバとノード設定情報を共有するステップであって、前記ノード設定情報は、ポイント・ツー・ポイントルーティングテーブル、非対称公開鍵、非対称秘密鍵、およびノード識別情報を含む、ステップを含む、請求項1に記載のコンピュータ実施方法。

【請求項3】

前記第1のブロックチェーンノードの前記第1のサーバを前記登録センタに登録するステップと、
前記登録センタからメッセージを受信するステップと、
前記登録センタからの前記メッセージに応答して、前記登録センタに前記第1のサーバのアドレスを送信するステップと
を含む、請求項1に記載のコンピュータ実施方法。

【請求項4】

前記取得したアドレスに基づいて前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記サービスリクエストを送信するステップは、
前記複数の追加のブロックチェーンノードの前記対応する複数のサーバの前記アドレスから第1のアドレスを選択するステップと、
前記サービスリクエストを前記第1のアドレスに送信するステップと
を含む、請求項1に記載のコンピュータ実施方法。

【請求項5】

前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップは、
前記サービスリクエストが有効であることを検証するステップと、
前記サービスリクエストが有効であることを検証したことに応答して、前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップと
を含む、請求項1に記載のコンピュータ実施方法。

【請求項6】

前記第1のブロックチェーンノードによって、前記第1のブロックチェーンノードの前記第1のサーバを選択するステップと、
前記第1のサーバによって、前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリから少なくとも1つのサービスリクエストを取得するステップと、
前記第1のサーバによって、前記少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージするステップと、
前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記プリプロセッシングブロックを送信するステップであって、追加のブロックチェーンノードの各々は、サービスコンセンサスを前記プリプロセッシングブロックに対して行う、ステップと
を含む、請求項1に記載のコンピュータ実施方法。

【請求項7】

前記登録センタから前記第1のブロックチェーンノードの前記第1のサーバによるハートビート検出メッセージを受信するステップをさらに含む、請求項1に記載のコンピュータ実施方法。

【請求項8】

1つまたは複数の命令を記憶している非一時的コンピュータ可読媒体であって、前記1つまたは複数の命令は、
コンセンサスネットワーク内の第1のブロックチェーンノードの第1のサーバによって、クライアントによって送信されたサービスリクエストを受信するステップであって、前記コンセンサスネットワークは、複数の追加のブロックチェーンノードをさらに含み、前記コンセンサスネットワークの前記第1のブロックチェーンノードおよび前記複数の追加のブロックチェーンノードの各ノードは、対応する複数のサーバを含む、ステップと、
前記第1のブロックチェーンノードの少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップと、
前記第1のブロックチェーンノードによって、登録センタから、前記コンセンサスネットワーク内の前記複数の追加のブロックチェーンノードの各ノードについての前記対応する複数のサーバの各サーバのアドレスを取得するステップと、
前記取得したアドレスに基づいて前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記サービスリクエストを送信するステップであって、追加のブロックチェーンノードの各々は、前記サービスリクエストを受信した後に対応する少なくとも1つのサービスメモリに前記サービスリクエストを記憶する、ステップと
を含む動作を行うようにコンピュータシステムによって実行可能である、非一時的コンピュータ可読媒体。

【請求項9】

前記第1のブロックチェーンノードの前記第1のサーバから、前記第1のブロックチェーンノードの複数の追加のサーバとノード設定情報を共有するステップであって、前記ノード設定情報は、ポイント・ツー・ポイントルーティングテーブル、非対称公開鍵、非対称秘密鍵、およびノード識別情報を含む、ステップを含む、請求項8に記載の非一時的コンピュータ可読媒体。

【請求項10】

前記第1のブロックチェーンノードの前記第1のサーバを前記登録センタに登録するステップと、
前記登録センタからメッセージを受信するステップと、
前記登録センタからの前記メッセージに応答して、前記登録センタに前記第1のサーバのアドレスを送信するステップと
を含む、請求項8に記載の非一時的コンピュータ可読媒体。

【請求項11】

前記取得したアドレスに基づいて前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記サービスリクエストを送信するステップは、
前記複数の追加のブロックチェーンノードの前記対応する複数のサーバの前記アドレスから第1のアドレスを選択するステップと、
前記サービスリクエストを前記第1のアドレスに送信するステップと
を含む、請求項8に記載の非一時的コンピュータ可読媒体。

【請求項12】

前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップは、
前記サービスリクエストが有効であることを検証するステップと、
前記サービスリクエストが有効であることを検証したことに応答して、前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップと
を含む、請求項8に記載の非一時的コンピュータ可読媒体。

【請求項13】

前記第1のブロックチェーンノードによって、前記第1のブロックチェーンノードの前記第1のサーバを選択するステップと、
前記第1のサーバによって、前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリから少なくとも1つのサービスリクエストを取得するステップと、
前記第1のサーバによって、前記少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージするステップと、
前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記プリプロセッシングブロックを送信するステップであって、追加のブロックチェーンノードの各々は、サービスコンセンサスを前記プリプロセッシングブロックに対して行う、ステップと
を含む、請求項8に記載の非一時的コンピュータ可読媒体。

【請求項14】

前記登録センタから前記第1のブロックチェーンノードの前記第1のサーバによるハートビート検出メッセージを受信するステップをさらに含む、請求項8に記載の非一時的コンピュータ可読媒体。

【請求項15】

コンピュータ実施システムであって、
1つまたは複数のコンピュータと、
前記1つまたは複数のコンピュータと相互運用可能なように結合されるとともに、1つまたは複数の命令を記憶している有形非一時的機械可読媒体を有する、1つまたは複数のコンピュータメモリデバイスとを含み、前記1つまたは複数の命令は、前記1つまたは複数のコンピュータによって実行されると、
コンセンサスネットワーク内の第1のブロックチェーンノードの第1のサーバによって、クライアントによって送信されたサービスリクエストを受信するステップであって、前記コンセンサスネットワークは、複数の追加のブロックチェーンノードをさらに含み、前記コンセンサスネットワークの前記第1のブロックチェーンノードおよび前記複数の追加のブロックチェーンノードの各ノードは、対応する複数のサーバを含む、ステップと、
前記第1のブロックチェーンノードの少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップと、
前記第1のブロックチェーンノードによって、登録センタから、前記コンセンサスネットワーク内の前記複数の追加のブロックチェーンノードの各ノードについての前記対応する複数のサーバの各サーバのアドレスを取得するステップと、
前記取得したアドレスに基づいて前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記サービスリクエストを送信するステップであって、追加のブロックチェーンノードの各々は、前記サービスリクエストを受信した後に対応する少なくとも1つのサービスメモリに前記サービスリクエストを記憶する、ステップと
を含む1つまたは複数の動作を行う、コンピュータ実施システム。

【請求項16】

前記第1のブロックチェーンノードの前記第1のサーバから、前記第1のブロックチェーンノードの複数の追加のサーバとノード設定情報を共有するステップであって、前記ノード設定情報は、ポイント・ツー・ポイントルーティングテーブル、非対称公開鍵、非対称秘密鍵、およびノード識別情報を含む、ステップを含む、請求項15に記載のコンピュータ実施システム。

【請求項17】

前記第1のブロックチェーンノードの前記第1のサーバを前記登録センタに登録するステップと、
前記登録センタからメッセージを受信するステップと、
前記登録センタからの前記メッセージに応答して、前記登録センタに前記第1のサーバのアドレスを送信するステップと
を含む、請求項15に記載のコンピュータ実施システム。

【請求項18】

前記取得したアドレスに基づいて前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記サービスリクエストを送信するステップは、
前記複数の追加のブロックチェーンノードの前記対応する複数のサーバの前記アドレスから第1のアドレスを選択するステップと、
前記サービスリクエストを前記第1のアドレスに送信するステップと
を含む、請求項15に記載のコンピュータ実施システム。

【請求項19】

前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップは、
前記サービスリクエストが有効であることを検証するステップと、
前記サービスリクエストが有効であることを検証したことに応答して、前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリに前記サービスリクエストを記憶するステップと
を含む、請求項15に記載のコンピュータ実施システム。

【請求項20】

前記第1のブロックチェーンノードによって、前記第1のブロックチェーンノードの前記第1のサーバを選択するステップと、
前記第1のサーバによって、前記第1のブロックチェーンノードの前記少なくとも1つのサービスメモリから少なくとも1つのサービスリクエストを取得するステップと、
前記第1のサーバによって、前記少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージするステップと、
前記コンセンサスネットワーク内の追加のブロックチェーンノードの各々に前記プリプロセッシングブロックを送信するステップであって、追加のブロックチェーンノードの各々は、サービスコンセンサスを前記プリプロセッシングブロックに対して行う、ステップと
を含む、請求項15に記載のコンピュータ実施システム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

コンピュータ技術の絶え間ない進歩に伴い、ブロックチェーン技術はより広く適用されている。効率的なデータ登録を実施することに加えて、人々はまた、いくつかのサービスを実施するための新たなアイデアを提供するために、ブロックチェーン技術を使用している。

【0003】

現時点、ブロックチェーン技術を使用してサービス処理を行うことは、おおよそ、サービス処理プロセスとサービスコンセンサスプロセスとの2つのプロセスを含む。サービス処理プロセスでは、ブロックチェーンノードは、ユーザによって送信されたサービスリクエストを受信し、ブロックチェーンノードのサービスメモリにサービスリクエストを記憶する。加えて、ブロックチェーンノードは、他のブロックチェーンノードがサービスリクエストを受信した後に他のブロックチェーンノードに対応するサービスメモリにサービスリクエストを記憶するように、サービスリクエストをコンセンサスネットワーク内の他のブロックチェーンノードにブロードキャストする。

【0004】

サービスコンセンサスプロセスでは、ブロックチェーンノードは、ブロックチェーンノードに対応するサービスメモリからある数量のサービスリクエストを取得し、取得したサービスリクエストを処理してプリプロセッシングブロックを取得する。その後、ブロックチェーンノードは、他のブロックチェーンノードがプリプロセッシングブロックを受信した後にサービスコンセンサスをプリプロセッシングブロックに対して行うように、プリプロセッシングブロックをコンセンサスネットワーク内の他のブロックチェーンノードにブロードキャストする。

【0005】

コンセンサスネットワーク内のブロックチェーンノード間における緊密な協調によってのみ、ブロックチェーンサービスのプロセスが効率的に完遂され得ることが上記で説明した2つのプロセスから理解できよう。しかしながら、実際には、ブロックチェーンノードは、通常、単一のサーバによって制限されており、このことは、比較的低い安定性を引き起こすことになる。例外、プログラム再起動などがサーバに発生すると、ブロックチェーンノードは利用不可となり、このことは、コンセンサスネットワーク全体の安定性に影響を及ぼすとともに、ブロックチェーンサービスのプロセスに影響を及ぼす。加えて、単一のサーバのソフトウェアおよびハードウェアのリソースは非常に制限されており、このことは、ブロックチェーンノードがサービス処理を行う際に比較的低い効率を引き起こすことになる。

【発明の概要】

【課題を解決するための手段】

【0006】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理方法を提供している。

【0007】

本出願の実施形態は、サービス処理方法を提供しており、サービス処理方法は、第1のブロックチェーンノードによって、第1のブロックチェーンノードに含まれているサーバを使用して、クライアントによって送信されたサービスリクエストを受信するステップであって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップと、第1のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するステップと、第2のブロックチェーンノードの各々がサービスリクエストを受信した後に第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するように、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するステップであって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップとを含む。

【0008】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理デバイスを提供している。

【0009】

本出願の実施形態は、サービス処理デバイスを提供しており、サービス処理デバイスは、クライアントによって送信されたサービスリクエストを受信するように構成される、受信モジュールと、サービス処理デバイスに対応するサービスメモリにサービスリクエストを記憶するように構成される、記憶モジュールと、第2のブロックチェーンノードの各々がサービスリクエストを受信した後に第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するように、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するように構成される、送信モジュールであって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、送信モジュールとを含む。

【0010】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理方法を提供している。

【0011】

本出願の実施形態は、サービス処理方法を提供しており、サービス処理方法は、第2のブロックチェーンノードによって、第2のブロックチェーンノードに含まれているサーバを使用して、第1のブロックチェーンノードによって送信されたサービスリクエストを受信するステップであって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含み、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップと、第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するステップとを含む。

【0012】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理デバイスを提供している。

【0013】

本出願の実施形態は、サービス処理デバイスを提供しており、サービス処理デバイスは、第1のブロックチェーンノードによって送信されたサービスリクエストを受信するように構成される、リクエスト受信モジュールであって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、リクエスト受信モジュールと、デバイスに対応するサービスメモリにサービスリクエストを記憶するように構成される、リクエスト記憶モジュールとを含む。

【0014】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理方法を提供している。

【0015】

本出願の実施形態は、サービス処理方法を提供しており、サービス処理方法は、クライアントによって、ユーザによって入力されたサービス情報を受信するステップと、サービス情報に基づいて対応するサービスリクエストを生成するステップと、第1のブロックチェーンノードが第1のブロックチェーンノードに含まれているサービスメモリに受信したサービスリクエストを記憶するように、サービスリクエストを第1のブロックチェーンノードに含まれているサーバに送信し、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するステップであって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含み、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップとを含む。

【0016】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理デバイスを提供している。

【0017】

本出願の実施形態は、サービス処理デバイスを提供しており、サービス処理デバイスは、ユーザによって入力されたサービス情報を受信するように構成される、情報受信モジュールと、サービス情報に基づいて対応するサービスリクエストを生成するように構成される、リクエスト生成モジュールと、第1のブロックチェーンノードが第1のブロックチェーンノードに含まれているサービスメモリに受信したサービスリクエストを記憶するように、サービスリクエストを第1のブロックチェーンノードに含まれているサーバに送信し、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するように構成される、送信モジュールであって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含み、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、送信モジュールとを含む。

【0018】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービスコンセンサス方法を提供している。

【0019】

本出願の実施形態は、サービスコンセンサス方法を提供しており、サービスコンセンサス方法は、第1のブロックチェーンノードによって、第1のブロックチェーンノードに含まれている複数のサーバからあるサーバを選択するステップであって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップと、選択したサーバを使用して第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得するステップと、第2のブロックチェーンノードの各々がサービスコンセンサスをプリプロセッシングブロックに対して行うように、選択したサーバを使用して少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージし、プリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するステップであって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップとを含む。

【0020】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービスコンセンサスデバイスを提供している。

【0021】

本出願の実施形態は、サービスコンセンサスデバイスを提供しており、サービスコンセンサスデバイスは、デバイスに対応するサービスメモリから少なくとも1つのサービスリクエストを取得するように構成される、リクエスト獲得モジュールと、第2のブロックチェーンノードの各々がサービスコンセンサスをプリプロセッシングブロックに対して行うように、少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージし、プリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するように構成される、送信モジュールであって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、送信モジュールとを含む。

【0022】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービスコンセンサスデバイスを提供している。

【0023】

本出願の実施形態は、サービスコンセンサスデバイスを提供しており、サービスコンセンサスデバイスは、第1のブロックチェーンノードに含まれている複数のサーバからあるサーバを選択するように構成される、選択モジュールであって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、選択モジュールを含む。

【0024】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービスコンセンサス方法を提供している。

【0025】

本出願の実施形態は、サービスコンセンサス方法を提供しており、サービスコンセンサス方法は、ブロックチェーンノードによって、ブロックチェーンノードに含まれている第1のサーバを使用してプリプロセッシングブロックを取得するステップであって、ブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップと、ブロックチェーンノードに含まれているサービスメモリに記憶されている各サービスリクエストに基づいて第1のサーバを使用してサービスコンセンサスをプリプロセッシングブロックに対して行うステップとを含む。

【0026】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービスコンセンサスデバイスを提供している。

【0027】

本出願の実施形態は、サービスコンセンサスデバイスを提供しており、サービスコンセンサスデバイスは、プリプロセッシングブロックを取得するように構成される、獲得モジュールと、デバイスに対応するサービスメモリに記憶されている各サービスリクエストに基づいてサービスコンセンサスをプリプロセッシングブロックに対して行うように構成される、コンセンサスモジュールとを含む。

【0028】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理方法を提供している。

【0029】

本出願の実施形態は、サービス処理方法を提供しており、サービス処理方法は、登録センタによって、コンセンサスネットワーク内の各ブロックチェーンノードに含まれている複数のサーバのアドレスを取得するステップであって、各ブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、ステップと、記憶のためにブロックチェーンノードに含まれている複数のサーバの取得したアドレスをコンセンサスネットワーク内の他のブロックチェーンノードおよびクライアントに送信するステップとを含む。

【0030】

本出願の実施形態は、ブロックチェーンノードがサービス処理を行う際に安定性が比較的低下するとともにサービス処理効率が比較的低下するという既存の技術における問題を解決するために、サービス処理デバイスを提供している。

【0031】

本出願の実施形態は、サービス処理デバイスを提供しており、サービス処理デバイスは、コンセンサスネットワーク内の各ブロックチェーンノードに含まれている複数のサーバのアドレスを取得するように構成される、獲得モジュールであって、各ブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、獲得モジュールと、記憶のためにブロックチェーンノードに含まれている複数のサーバの取得したアドレスをコンセンサスネットワーク内の他のブロックチェーンノードおよびクライアントに送信する、送信モジュールとを含む。

【0032】

本出願の実施形態において使用される上記で説明した少なくとも1つの技術的ソリューションが、以下の有益な効果を達成し得る。

【0033】

本出願の実施形態においては、第1のブロックチェーンノードは複数のサーバを含む。第1のブロックチェーンノードは、クライアントによって送信されたサービスリクエストを受信し、第1のブロックチェーンノードに含まれている1つのサーバを使用してサービスリクエストを記憶し、第1のブロックチェーンノードに含まれているサーバを使用して第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得し、プリプロセッシングブロックを取得し、サーバを使用してプリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信して、第2のブロックチェーンノードの各々を使用してサービスコンセンサスをプリプロセッシングブロックに対して行い得る。第1のブロックチェーンノードに含まれている複数のサーバのうちの1つのサーバが利用可能であるならば、第1のブロックチェーンノードが利用可能であることを保証し得る。したがって、コンセンサスネットワーク内の第1のブロックチェーンノードの安定性を大幅に改善している。加えて、第1のブロックチェーンノードに含まれている各サーバは、クライアントを使用してユーザによって送信されたサービスリクエストを受信し得るし、各サーバは、コンセンサスネットワーク内の第2のブロックチェーンノードの各々に対するサービスコンセンサスを開始し得る。したがって、ブロックチェーンサービスのサービス処理効率が大幅に改善される。

【0034】

本明細書で記載した添付の図面は、本出願の更なる理解を提供することを意図しており、本出願の一部分を構成する。本出願の事例示的な実施形態および本出願の実施形態の説明は、本出願を説明することを意図したものであり、本出願に対する限定を構成するものではない。添付の図面は以下の通りである。

【図面の簡単な説明】

【0035】

【図1】本出願の実施形態による、サービスコンセンサスプロセスを図示している概略図である。

【図2】本出願の実施形態による、登録センタによってアドレスをクライアントにプッシュする概略図である。

【図3】本出願の実施形態による、登録センタによって第2のブロックチェーンノードにある各サーバのアドレスを第1のブロックチェーンノードにある各サーバにプッシュする概略図である。

【図4】本出願の実施形態による、サーバによって検証対象となる識別子を決定する概略図である。

【図5】本出願の実施形態による、第2のブロックチェーンノードにあるサーバによってサービスコンセンサスをプリプロセッシングブロックに対して行うプロセスを図示している概略図である。

【図6】本出願の実施形態による、サービス処理デバイスを図示している概略構造図である。

【図7】本出願の実施形態による、サービス処理デバイスを図示している概略構造図である。

【図8】本出願の実施形態による、サービス処理デバイスを図示している概略構造図である。

【図9】本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図である。

【図10】本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図である。

【図11】本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図である。

【図12】本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図である。

【発明を実施するための形態】

【0036】

当業者に本出願における技術的ソリューションをより良く理解してもらうべく、本出願の実施形態における添付の図面を参照して、本出願の実施形態における技術的ソリューションを以下に明確かつ十分に説明している。説明した実施形態が本出願の実施形態のすべてではなく一部に過ぎないことは明白であろう。創造的努力無しで本出願の実施形態に基づいて当業者によって得られるすべての他の実施形態は、本出願の保護範囲に含まれるものとする。

【0037】

図1は、本出願の実施形態による、サービスコンセンサスプロセスを図示している概略図であり、特に、以下のステップを含む。

【0038】

S101. 第1のブロックチェーンノードが、第1のブロックチェーンノードに含まれている複数のサーバのうちのあるサーバを使用して、クライアントによって送信されたサービスリクエストを受信する。

【0039】

本出願の本実施形態においては、サービス処理プロセスでは、ユーザは、クライアントを使用してサービスリクエストを第1のブロックチェーンノードに送信し得る。本明細書に記載のクライアントは、ユーザによって把持されているエンドユーザデバイスにインストールされているクライアントであり得る。ユーザは、エンドユーザデバイス上でクライアントを開始し、ユーザにクライアントによって表示されるインターフェース上でサービス情報を入力し得る。ユーザによって入力されたサービス情報を受信した後に、クライアントは、クライアントに事前に記憶されているサービスロジックに基づいて対応するサービスリクエストを生成し、エンドユーザデバイスを使用してサービスリクエストを第1のブロックチェーンノードに送信し得る。

【0040】

当然のことながら、本出願の本実施形態においては、ユーザは、対応するサービス情報をエンドユーザデバイスに直接入力し得るし、エンドユーザデバイスは、ユーザによって入力されたサービス情報に基づいて対応するサービスリクエストを生成し、サービスリクエストを第1のブロックチェーンノードに送信し得る。

【0041】

本出願の本実施形態においては、第1のブロックチェーンノードは、複数のサーバを含み(換言すれば、第1のブロックチェーンノードは、サーバクラスタを含み、サーバクラスタは、第1のブロックチェーンノードに相当する)、サーバは、ポイント・ツー・ポイントルーティングテーブル、ノードの非対称な公開鍵/秘密鍵、およびノード識別情報(ID)などのノード設定情報を共有する。したがって、コンセンサスネットワーク内の他のブロックチェーンノードおよびクライアントについては、第1のブロックチェーンノードにあるサーバによって行われる動作はすべて、第1のブロックチェーンノードによって行われているとみなされる。

【0042】

したがって、サービスリクエストを第1のブロックチェーンノードに送信する場合には、クライアントは、サービスリクエストを送信すべき第1のブロックチェーンノードにあるサーバをまず決定する必要がある。したがって、本出願の本実施形態は、登録センタを提供する。登録センタは、ブロックチェーンノードにある複数のサーバの複数のアドレスを管理し、複数のサーバの複数のアドレスをクライアントにプッシュするように構成される。クライアントは、図2に示した、登録センタによってプッシュされた複数のアドレスからあるアドレスをランダムに選択し、サービスリクエストをアドレスに対応するサーバに送信することをし得る。

【0043】

図2は、本出願の実施形態による、登録センタによってアドレスをクライアントにプッシュする概略図である。

【0044】

図2では、第1のブロックチェーンノードは、複数のサーバを含み、各サーバは、オンライン(本明細書に記載の「オンライン」は、サーバがサービス処理を正常に行うことを開始することを意味する)である場合に、登録センタに登録し得る、換言すれば、サーバが、現時点利用可能な状態であり、クライアントによって送信されたサービスリクエストを受信し得ることを登録センタに通知し得る。サーバがオンラインであると決定した後に、登録センタは、サーバのアドレスを取得し得る、その後、クライアントがアドレスを受信した後にアドレスを記憶するように、そのアドレスにクライアントにプッシュし得る。

【0045】

本出願の本実施形態においては、登録センタは、サーバからサーバのアドレスを先を見越して取得し得る、または、サーバは、登録センタのためのアドレスを提供し得る。例えば、サーバが登録センタに登録した後に、登録センタは、登録成功メッセージをサーバに返信し得る。サーバは、登録センタがアドレスを管理するように、メッセージを受信した後に、サーバのアドレスを登録センタに先を見越して送信し得る。

【0046】

その上、登録センタは、取得したアドレスをクライアントに先を見越してプッシュし得るし、クライアントも、登録センタによって管理されるアドレスを先を見越して取得し得る。例えば、サービスリクエストを第1のブロックチェーンノードに送信することに加えて、クライアントは、アドレス獲得クエリメッセージを登録センタにさらに送信し得る。クエリメッセージを受信した後に、登録センタは、登録センタによって送信された複数のアドレスを受信した後に、クライアントが、複数のアドレスからあるアドレスを選択し、サービスリクエストを選択したアドレスに対応するサーバに送信するように、第1のブロックチェーンノードにある現時点利用可能なサーバ(すなわち、登録センタに現時点登録しているサーバ)のアドレスをクライアントに送信し得る。当然のことながら、クライアントはまた、他の方法を使用して、登録センタから第1のブロックチェーンノードに含まれているサーバのアドレスを取得し得る。詳細はここでは省略する。

【0047】

実際には、動作障害、プログラム再起動などにより、第1のブロックチェーンノードにあるサーバがオフラインである(換言すれば、サーバがサービス処理を行うことができない)可能性があることに留意されたい。登録センタがオフラインのサーバのアドレスをクライアントに送信し、クライアントがサーバ選択においてオフラインのサーバのアドレスをその通りに選択した場合には、クライアントは、サービスリクエストを第1のブロックチェーンノードに送信できない可能性があり、第1のブロックチェーンノードは、サービスリクエストを処理できなくなる。

【0048】

そのような問題を回避するために、本出願の本実施形態においては、登録センタは、ハートビート検出メッセージを登録センタに既に登録している各サーバに定期的に送信し得る。サーバは、正常にオンラインで動作している場合には、受信したハートビート検出メッセージに基づいて、応答メッセージを登録センタに返信し得る。応答メッセージを受信した後に、登録センタは、サーバが正常にオンラインで動作していると決定し得るし、サーバのアドレスを管理することを継続する。

【0049】

ハートビート検出メッセージをサーバに送信した後に、ハートビート検出メッセージに基づいてサーバによって返信された応答メッセージが指定の時間が経過した後に受信されなかった場合には、登録センタは、動作障害、プログラム再起動などにより、サーバが現時点オフラインである可能性があると決定し得るし、サーバのアドレスをクライアントにプッシュしない。加えて、登録センタがサーバのアドレスをクライアントにプッシュしていた場合には、登録センタは、クライアントが通知に基づいてサーバのアドレスをローカルで削除するように、サーバがオフラインである通知をクライアントに送信し得る。

【0050】

オフラインのサーバのアドレスを決定した後では、クライアントは、サービスリクエストをサーバに送信しない。サーバがオンラインに戻ると、クライアントは、登録センタからサーバのアドレスを再取得し、そのアドレスを使用してサービスリクエストをサーバに送信する。

【0051】

図2は、クライアントが登録センタから第1のブロックチェーンノードに含まれているアドレスを取得している例を使用して説明しているに過ぎないことに留意されたい。図2では、第1のブロックチェーンノードがクライアントからクライアントによって送信されたサービスリクエストを受信し得るため、第1のブロックチェーンノードにあるサーバは、登録センタが第1のブロックチェーンノードにあるサーバのアドレスをクライアントにプッシュすることができ、クライアントが取得したアドレスを使用してサービスリクエストを第1のブロックチェーンノードにあるサーバに送信することができるように、登録センタに登録する必要がある。

【0052】

しかしながら、実際には、コンセンサスネットワーク内の第2のブロックチェーンノードも、クライアントによって送信されたサービスリクエストを受信し、サービスリクエストを処理し得る。したがって、本出願の本実施形態においては、コンセンサスネットワーク内の第2のブロックチェーンノードの各々に含まれているサーバも、登録センタが第2のブロックチェーンノードに含まれているサーバのアドレスをクライアントにプッシュすることができるように、登録センタに登録し得る。そのため、クライアントはまた、取得したアドレスを使用してサービスリクエストを第2のブロックチェーンノードにあるサーバに送信し得る。

【0053】

S102. サーバを使用して、第1のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶し、第2のブロックチェーンノードの各々がサービスリクエストを受信した後に第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するように、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信する。

【0054】

クライアントによって送信されたサービスリクエストを受信した後に、第1のブロックチェーンノードに含まれているサーバは、第1のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶し得る。加えて、サーバは、第2のブロックチェーンノードがサービスリクエストを受信した後に第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するように、クライアントによって送信されたサービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信し得る。

【0055】

第1のブロックチェーンノードにあるサーバは、まず、サービスリクエストを受信した後に、有効検証をサービスリクエストに対して行い得る。有効検証は、RSAアルゴリズムなどの非対称シグニチャを使用した有効検証であり得る、または、他の形式の検証であり得る。サービスリクエストが有効検証に成功したと決定すると、サーバは、第1のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶し、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信し得る。サービスリクエストが有効検証に成功しなかったと決定すると、サーバは、サービスリクエストを記憶することはしないが、ユーザがクライアントを使用してメッセージを読んだ後に何らかの操作を行うように、サービスリクエストを処理することに失敗したことを含むメッセージをクライアントに返信し得る。例えば、ユーザは、メッセージを読んだ後に、クライアントにおいてサービスリクエストを再編集し、クライアントを使用して、編集したサービスリクエストを第1のブロックチェーンノードに含まれているサーバに送信し得る。

【0056】

本出願の本実施形態においては、コンセンサスネットワーク内の各ブロックチェーンノードは、複数のサーバを含み得る。したがって、サービスリクエストを第2のブロックチェーンノードに送信する場合には、第1のブロックチェーンノードにあるサーバも、第2のブロックチェーンノードにあるサーバのアドレスを取得する必要があり、その後、取得したアドレスを使用してサービスリクエストを第2のブロックチェーンノードに含まれているサーバに送信する。

【0057】

したがって、本出願の本実施形態においては、登録センタはまた、図3に示した、第2のブロックチェーンノードにあるサーバのアドレスを管理し、第2のブロックチェーンノードにあるサーバのアドレスを第1のブロックチェーンノードにある各サーバに送信する必要がある。

【0058】

図3は、本出願の実施形態による、登録センタによって第2のブロックチェーンノードにある各サーバのアドレスを第1のブロックチェーンノードにある各サーバにプッシュする概略図である。

【0059】

図3では、第2のブロックチェーンノードにあるサーバも、登録センタが第2のブロックチェーンノードにあるサーバのアドレスを取得するように、オンラインであった後に登録センタに登録し得る。登録センタは、第2のブロックチェーンノードにあるサーバからアドレスを先を見越して取得し得る、または、第2のブロックチェーンノードにあるサーバは、それらのアドレスを登録センタに先を見越して送信し得る。具体的な方法は、登録センタによって第1のブロックチェーンノードにあるサーバのアドレスを取得するステップS101において上記で説明した方法と同一であるため、詳細はここでは省略する。

【0060】

登録センタを使用して第2のブロックチェーンノードにあるサーバのアドレスを取得した後に、第1のブロックチェーンノードにある各サーバは、取得したアドレスを記憶し得る。サービスリクエストを第2のブロックチェーンノードに送信する場合には、第1のブロックチェーンノードにあるサーバは、第2のブロックチェーンノードに含まれている記憶されているアドレスからアドレスを選択し、その後、アドレスに対応するサーバがサービスリクエストを受信した後に第2のブロックチェーンノードに対応するサービスメモリにサービスリクエストを記憶するように、サービスリクエストをアドレスに対応するサーバに送信し得る。

【0061】

第2のブロックチェーンノードにあるサーバは、サービスリクエストを受信した後に、有効検証をサービスリクエストに対して行い得る。サーバは、サービスリクエストが有効検証に成功したと決定すると、第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶し得る。サーバは、サービスリクエストが有効検証に成功しなかったと決定すると、サービスリクエストを記憶しない。

【0062】

第2のブロックチェーンノードに含まれているサーバもステップS101において記載したようにオフラインである可能性があることに留意されたい。したがって、第2のブロックチェーンノードにあるサーバのアドレスを取得した後に、登録センタは、ハートビート検出メッセージをこれらのアドレスに対応するサーバに定期的に送信し得る。指定の時間が経過した後に(または、指定の時間内に)ハートビート検出メッセージに基づいてサーバによって返信された応答メッセージを受信した場合には、登録センタは、サーバがまだオンライン状態であると決定し得るし、サーバのアドレスを管理することを継続する。指定の時間が経過した後にハートビート検出メッセージに基づいてサーバによって返信された応答メッセージを受信しなかった場合には、登録センタは、動作障害、ネットワークの不安定性などにより、サーバがオフラインである可能性があると決定し、サーバがオンラインに戻るまでサーバのアドレスを管理することを継続しない。

【0063】

加えて、上記で説明した方法を使用して、第2のブロックチェーンノードにある、あるサーバがオフラインであると決定した場合には、登録センタは、第1のブロックチェーンノードにあるサーバおよびクライアントが通知を受信した後にサーバのアドレスを削除し、その後、サーバがオンラインに戻るまでサービスリクエストをアドレスに対応するサーバに送信しないように、サーバがオフラインである通知を第1のブロックチェーンノードにあるサーバおよびクライアントに送信し得る。登録センタからサーバのアドレスを再取得した後に、第1のブロックチェーンノードにあるサーバおよびクライアントは、取得したアドレスを使用してサービスリクエストをアドレスに対応するサーバに送信し得る。

【0064】

図3は、1つの第2のブロックチェーンノードに含まれているサーバが登録センタに登録しているケースを示しているに過ぎない。実際には、コンセンサスネットワークには複数の第2のブロックチェーンノードが存在する。したがって、コンセンサスネットワーク内の第2のブロックチェーンノードの各々におけるサーバは、登録センタが、第2のブロックチェーンノードにあるサーバのアドレスを取得し、取得したアドレスを第1のブロックチェーンノードにあるサーバにプッシュするように、オンラインであった後に登録センタに登録し得る。換言すれば、第1のブロックチェーンノードにある各サーバは、コンセンサスネットワーク内の第2のブロックチェーンノードの各々に含まれているサーバのアドレスを記憶する。

【0065】

実際には、コンセンサスネットワーク全体は、複数のブロックチェーンノードを含むことに留意されたい。本出願の本実施形態において記載したように第1のブロックチェーンノードは、クライアントによって送信されたサービスリクエストを受信するブロックチェーンノードであり、第1のブロックチェーンノード以外の他のブロックチェーンノードを本出願の本実施形態においては第2のブロックチェーンノードと称し得る。第1のブロックチェーンノードと第2のブロックチェーンノードとは相対的な用語である。具体的には、クライアントからサービスリクエストを受信するブロックチェーンノードを第1のブロックチェーンノードと称し得るし、第1のブロックチェーンノードによって送信されたサービスリクエストを受信するブロックチェーンノードを第2のブロックチェーンノードと称し得る。コンセンサスネットワーク内のブロックチェーンノードはすべて、クライアントによって送信されたサービスリクエストを受信し得るため、ブロックチェーンノードは、本質的に、第1のブロックチェーンノード、または第2のブロックチェーンノードであり得る。第1のブロックチェーンノードと第2のブロックチェーンノードとの間の相違は、サービスリクエストを受信しているかに依存する。

【0066】

当然のことながら、コンセンサスチェックプロセスでは、第1のブロックチェーンノードと第2のブロックチェーンノードとの間の相違はまた、どのノードがコンセンサスチェックを開始したかに基づいて決定され得る。具体的には、少なくとも1つのサービスリクエストを含むプリプロセッシングブロックをコンセンサスネットワークに送信するコンセンサスチェックの始端は、第1のブロックチェーンノードであり得るし、プリプロセッシングブロックを受信するブロックチェーンノードを第2のブロックチェーンノードと称し得る。

【0067】

S103. サービスコンセンサスフェーズにおいて、第1のブロックチェーンノードに含まれている複数のサーバからあるサーバを選択し、選択したサーバを使用して第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得する。

【0068】

本出願の本実施形態においては、第1のブロックチェーンノードにあるサーバは、サービスコンセンサスを第1のブロックチェーンノードに含まれているサービスメモリにあるサービスリクエストに対して行う必要がある。したがって、サービスコンセンサスフェーズにおいては、第1のブロックチェーンノードにあるサーバは、第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得し、その後、取得したサービスリクエストをプリプロセッシングブロックにパッケージし、プリプロセッシングブロックをサービスコンセンサスのためにコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信し得る。

【0069】

本出願の本実施形態においては、複数のサーバおよびサービスメモリに加えて、第1のブロックチェーンノードは、予定されていたタスクトリガをさらに含み、予定されていたタスクトリガは、第1のブロックチェーンノードにあるサーバを使用してコンセンサスネットワーク内の各ブロックチェーンノードに対するサービスコンセンサスを周期的に開始するために使用される。しかしながら、第1のブロックチェーンノードが複数のサーバを含むため、予定されていたタスクトリガは、サービスコンセンサスフェーズにおいて第1のブロックチェーンノードに含まれている複数のサーバからあるサーバを選択し得るし、その後、サーバは、第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得する。

【0070】

本出願の本実施形態においては、予定されていたタスクトリガは、ハードウェアデバイスであり得る、または、ソフトウェアの形式であり得る。ソフトウェアの形式については、予定されていたタスクトリガは、第1のブロックチェーンノードにある、あるサーバに設定され得る。サーバにおいて動作している場合には、予定されていたタスクトリガは、サービスコンセンサスフェーズにおいて第1のブロックチェーンノードに含まれているサーバからサーバを選択し、選択したサーバが通知を受信した後に第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのリクエストを取得するように、予定されていたタスクトリガがあるサーバを使用して通知を選択したサーバに送信し得る。

【0071】

サービスメモリ(すなわち、第1のブロックチェーンノードに含まれているサービスメモリ)から各サービスリクエストを取得するプロセスでは、サーバは、各サービスリクエストがサービスメモリに記憶している時間シーケンスに基づいて各サービスリクエストを取得し得る、または、サービスタイプの各サービスリクエストに基づいて各サービスリクエストを取得し得る、または、各サービスリクエストのサービスレベルに基づいて各サービスリクエストを取得し得る。多くの獲得方法が存在するため、詳細はここでは省略する。

【0072】

S104: 第2のブロックチェーンノードの各々がサービスコンセンサスをプリプロセッシングブロックに対して行うように、選択したサーバを使用して少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージし、選択したサーバを使用してプリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信する。

【0073】

第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得した後に、第1のブロックチェーンノードにあるサーバは、取得したサービスリクエストを処理し、サービスリクエストをプリプロセッシングブロックにパッケージし得る。サーバは、所定のソート処理ルールに基づいて取得したサービスリクエストをソートしてサービスリクエストのソート処理結果を取得し、所定の識別子決定ルールおよびソート処理結果を使用して、サービスリクエストに一意に対応する検証対象となる識別子を決定し得る。その後、サーバは、取得したサービスリクエスト、サービスリクエストのソート処理結果、および決定した検証対象となる識別子を、1つのプリプロセッシングブロックにパッケージし、その後、プリプロセッシングブロックを第2のブロックチェーンノードに含まれているサーバに送信し得る。

【0074】

サーバによって検証対象となる識別子を決定する特定の方法を図4に示し得る。

【0075】

図4は、本出願の実施形態による、サーバによって検証対象となる識別子を決定する概略図である。

【0076】

図4では、第1のブロックチェーンノードにあるサーバ(すなわち、第1のブロックチェーンノードに含まれている予定されていたタスクトリガを使用して決定されたサーバ)は、第1のブロックチェーンノードに含まれているサービスメモリから図4に示した4つのサービスリクエストを取得する。サーバは、所定のソート処理ルールに基づいて4つのサービスリクエストをソートして、図4に示したソート処理結果を取得し得る。その後、サーバは、ハッシュアルゴリズムといった所定の識別子決定ルールに基づいて4つのサービスリクエストに対応する子識別子Hash1からHash4を別々に決定し、取得したソート処理結果に基づいて左から右へとMerkleツリーのリーフノードに決定した4つの子識別子をセットして、Merkleツリーのルートノードにおける値Hash7を決定し得る。サーバは、Merkleツリーのルートノードにおける決定した値Hash7を、4つのサービスリクエストに一意に対応する検証対象となる識別子として決定し、その後、決定した検証対象となる識別子、ソート処理結果、および4つのサービスリクエストを、1つのプリプロセッシングブロックにパッケージし得る。

【0077】

図4に示した検証対象となる識別子を決定する方法が唯一なものではないことに留意されたい。例えば、所定の識別子決定ルールとしてハッシュアルゴリズムを使用してサービスリクエストに一意に対応する検証対象となる識別子を決定することに加えて、第1のブロックチェーンノードにあるサーバは、決定した検証対象となる識別子がサービスリクエストに一意に対応するならば、メッセージダイジェストアルゴリズム5(MD5)などのアルゴリズムを使用して、サービスリクエストに一意に対応する検証対象となる識別子をさらに決定し得る。図4に示した形式に加えて、Merkleツリーは他の形式をさらに有し得る。詳細はここでは省略する。

【0078】

当然のことながら、本出願の本実施形態においては、Merkleツリーに加えて、第1のブロックチェーンノードにあるサーバは、他の方法を使用して、サービスリクエストに一意に対応する検証対象となる識別子をさらに決定し得る。例えば、サービスリクエストに対応する子識別子を決定した後に、サーバは、あるシーケンスに基づいて決定した子識別子をソートし、ソートした結果を再度暗号化し、サービスリクエストに一意に対応する検証対象となる識別子として暗号化した結果を使用し得る。あるいは、サービスリクエストに対応する子識別子を決定した後に、サーバは、スノーフレークアルゴリズムを使用して一意なIDを汎用的に生成し、サービスリクエストに一意に対応する検証対象となる識別子としてIDを使用し得る。あるいは、サーバは、サービスリクエストに対応する決定した子識別子の汎用一意識別子(UUID)を決定し、サービスリクエストに一意に対応する検証対象となる識別子としてUUIDを使用し得る。当然のことながら、決定した検証対象となる識別子がサービスリクエストに一意に対応し得ることが保証されているならば、他の決定方法がさらに存在するため、詳細はここでは省略する。

【0079】

プリプロセッシングブロックを決定した後に、第1のブロックチェーンノードにあるサーバ(すなわち、サービスコンセンサスフェーズにおいて第1のブロックチェーンノードにある予定されていたタスクトリガを使用して選択されるサーバ)は、プリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信し得る。しかしながら、コンセンサスネットワーク内の第2のブロックチェーンノードの各々は複数のサーバを含む。したがって、プリプロセッシングブロックを送信する場合には、第1のブロックチェーンノードにあるサーバは、プリプロセッシングブロックが送信される第2のブロックチェーンノードの各々におけるサーバを決定する必要がある。

【0080】

本出願の本実施形態においては、第1のブロックチェーンノードにある各サーバは、登録センタからコンセンサスネットワーク内の第2のブロックチェーンノードの各々に含まれているサーバのアドレスを取得し得る。したがって、第1のブロックチェーンノードにあるサーバがプリプロセッシングブロックをコンセンサスネットワーク内のある第2のブロックチェーンノードに送信する必要がある場合には、サーバは、第2のブロックチェーンノードにあるサーバの記憶されているアドレス(記憶されているアドレスは、オンライン状態である第2のブロックチェーンノードにあるサーバのアドレスである)からアドレスを選択し、アドレスに対応するサーバがプリプロセッシングブロックを受信した後にコンセンサスチェックをプリプロセッシングブロックに対して行うように、プリプロセッシングブロックをアドレスに対応するサーバに送信し得る。

【0081】

コンセンサスネットワークに複数の第2のブロックチェーンノードが存在する。したがって、プリプロセッシングブロックを第2のブロックチェーンノードの各々に送信する場合には、第1のブロックチェーンノードにあるサーバは、上記で説明した方法を使用して、記憶されているアドレスから、プリプロセッシングブロックを受信する第2のブロックチェーンノードの各々におけるサーバを別々に決定し、その後、決定したアドレスを使用してプリプロセッシングブロックを第2のブロックチェーンノードの各々におけるサーバに別々に送信し得る。

【0082】

第2のブロックチェーンノードについては、第1のブロックチェーンノードにあるサーバによって送信されたプリプロセッシングブロックを受信した後に、第2のブロックチェーンノードに含まれているサーバは、プリプロセッシングブロックを解析して、プリプロセッシングブロックに含まれているサービスリクエスト、サービスリクエストのソート処理結果、および検証対象となる識別子を決定し得る。その後、第2のブロックチェーンノードにあるサーバは、第2のブロックチェーンノードに含まれているサービスメモリからプリプロセッシングブロックに含まれているサービスリクエストに一致するサービスリクエストを発見し、所定の識別子決定ルールおよびサービスリクエストの決定したソート処理結果を使用して、第2のブロックチェーンノードに含まれているサービスメモリから見つかったサービスリクエストに一意に対応する識別子を決定し得る。本明細書に記載の所定の識別子決定ルールは、第1のブロックチェーンノードにあるサーバによって使用される識別子決定ルールと同一である。

【0083】

第2のブロックチェーンノードにあるサーバは、識別子を決定した後に、プリプロセッシングブロックに含まれている検証対象となる識別子と決定した識別子を比較し得るし、2つが一致していると決定した場合には、プリプロセッシングブロックがローカルコンセンサスチェックに成功した(換言すれば、第2のブロックチェーンノードにあるサーバによって行われたものである)と決定し、その後、第2のブロックチェーンノードに含まれているサービスメモリにチェック結果を記憶し、チェック結果をコンセンサスネットワーク内の他のブロックチェーンノード(本明細書に記載の他のブロックチェーンノードは、第2のブロックチェーンノードの各々および第1のブロックチェーンノードを含む)に送信し得る。

【0084】

第2のブロックチェーンノードにあるサーバによってチェック結果を送信する方法は、第1のブロックチェーンノードにあるサーバによってサービスリクエストまたはプリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信する方法と同一である。具体的には、第2のブロックチェーンノードにあるサーバがチェック結果をコンセンサスネットワーク内のあるブロックチェーンノード(第2のブロックチェーンノードであり得る、または第1のブロックチェーンノードであり得る)に送信する必要がある場合には、サーバは、ブロックチェーンノードにあるサーバのローカルに記憶されているアドレスからアドレスを選択し、チェック結果をアドレスに対応するサーバに送信し得る。チェック結果を受信した後に、アドレスに対応するサーバは、サーバが属するブロックチェーンノードに含まれているサービスメモリにチェック結果を記憶し得る。

【0085】

第2のブロックチェーンノードにあるサーバがチェック結果をコンセンサスネットワーク内の各ブロックチェーンノードに送信する場合には、第2のブロックチェーンノードにある他のサーバまたは前記サーバも、コンセンサスネットワーク内の他のブロックチェーンノードによって送信されたプリプロセッシングブロックに関するチェック結果を受信し、第2のブロックチェーンノードに含まれているサービスメモリに受信したチェック結果のすべてを記憶し得る。その後、第2のブロックチェーンノードにあるサーバ(サーバは、プリプロセッシングブロックを受信するサーバであり得る)は、第2のブロックチェーンノードに含まれているサービスメモリから、コンセンサスネットワーク内の各ブロックチェーンノードによって取得されたプリプロセッシングブロックに関するチェック結果(サーバによって取得されたチェック結果を含む)を決定し、コンセンサスネットワーク内の各ブロックチェーンノードによって取得されたプリプロセッシングブロックに関する包括的チェック結果を決定し得る。その後、サーバは、チェック結果を送信するものと同一の方法を使用して、決定した包括的チェック結果をコンセンサスネットワーク内の各ブロックチェーンノードに送信し、第2のブロックチェーンノードに含まれているサービスメモリに包括的チェック結果を記憶し得る。

【0086】

第2のブロックチェーンノードにあるサーバが包括的チェック結果を送信した後に、第2のブロックチェーンノードにある他のサーバまたは前記サーバ(すなわち、包括的チェック結果を送信するサーバ)も、コンセンサスネットワーク内の各ブロックチェーンノード(第2のブロックチェーンノードの各々および第1のブロックチェーンノードを含む)によって送信されたプリプロセッシングブロックに関する包括的チェック結果を受信し、第2のブロックチェーンノードに含まれているサービスメモリに包括的チェックを記憶し得る。

【0087】

第2のブロックチェーンノードにあるサーバ(すなわち、包括的チェック結果を送信するサーバ)は、第2のブロックチェーンノードに含まれているサービスメモリからコンセンサスネットワーク内の他のブロックチェーンノードによって送信された包括的チェック結果を取得し、受信した包括的チェック結果およびサーバによって決定された包括的チェック結果を使用して、プリプロセッシングブロックがコンセンサスネットワークにおけるサービスコンセンサスに成功したかどうかを決定し、サービスメモリに記憶されている包括的チェック結果(サーバによって決定された包括的チェック結果を含む)に基づいて、プリプロセッシングブロックに含まれている各サービスリクエストがコンセンサスネットワークにおけるサービスコンセンサスに成功したと決定すると、プリプロセッシングブロックに含まれている各サービスリクエストを第2のブロックチェーンノードが記録されているブロックチェーンに書き込み得る、またさもなければ、各サービスリクエストをブロックチェーンに書き込まない。第2のブロックチェーンノードにあるサーバは、各サービスリクエストのコンテンツ全体をブロックチェーンに書き込み得る、または、各サービスリクエストの情報ダイジェストのみをブロックチェーンに書き込み得る。

【0088】

上記で説明したサービスコンセンサスプロセスは比較的複雑である。理解を容易にするために、以下では、図5に示した、第2のブロックチェーンノードにあるサーバによってサービスコンセンサスをプリプロセッシングブロックに対して行うプロセスを明確に説明するための簡略な例を列挙している。

【0089】

図5は、本出願の実施形態による、第2のブロックチェーンノードにあるサーバによってサービスコンセンサスをプリプロセッシングブロックに対して行うプロセスを図示している概略図である。

【0090】

コンセンサスネットワークに、第1のブロックチェーンノード、第2のブロックチェーンノードA、および第2のブロックチェーンノードBといった3つのブロックチェーンノードが存在していると仮定する。3つのブロックチェーンノードにある各サーバは、他の2つのブロックチェーンノードに含まれているサーバのアドレスをそれぞれ記憶する。第1のブロックチェーンノードにあるサーバ#3は、第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得する、少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージし、プリプロセッシングブロックを他の2つのブロックチェーンノードに送信する。サーバ#3は、サーバ#3に記憶されている他の2つのブロックチェーンノードに含まれているサーバのアドレスを使用して、プリプロセッシングブロックをサーバA1およびサーバB1に別々に送信すると決定する。

【0091】

プリプロセッシングブロックを受信した後に、サーバA1およびサーバB1は、コンセンサスチェックをプリプロセッシングブロックに対して行い、サーバA1およびサーバB1が属するブロックチェーンノードに含まれているサービスメモリにプリプロセッシングブロックについての取得したチェック結果をそれぞれ記憶し得る。加えて、サーバA1およびサーバB1は、決定したチェック結果をコンセンサスネットワーク内の他の2つのブロックチェーンノードにそれぞれ送信し得る。サーバA1は、サーバA1に記憶されている他の2つのブロックチェーンノードにあるサーバのアドレスに基づいて、サーバA1によって取得されたチェック結果を第1のブロックチェーンノードにあるサーバ#2および第2のブロックチェーンノードBにあるサーバB2に送信すると決定し、サーバB1は、サーバB1によって取得されたチェック結果を第1のブロックチェーンノードにあるサーバ#3および第2のブロックチェーンノードAにあるサーバA3に送信すると決定する。

【0092】

他の2つのブロックチェーンノードにあるサーバによって送信されたチェック結果を別々に受信した後に、コンセンサスネットワーク内の3つのブロックチェーンノードにあるサーバは、ブロックチェーンノードに含まれているサービスメモリに受信したチェック結果を記憶し得る。サーバA1(すなわち、プリプロセッシングブロックを受信するサーバ)は、第2のブロックチェーンノードAに含まれているサービスメモリからチェック結果(サーバA1によって取得されたチェック結果を含む)を取得し、これらのチェック結果に基づいてプリプロセッシングブロックについてのコンセンサスネットワーク内のブロックチェーンノードの包括的チェック結果を取得し得る。サーバA1は、第2のブロックチェーンノードAに含まれているサービスメモリに取得した包括的チェック結果を記憶し、包括的チェック結果を他の2つのブロックチェーンノードに送信し得る。送信方法は、チェック結果を送信する方法と同一であるため、詳細はここでは省略する。サーバ#3(すなわち、サービスコンセンサスを送信するサーバ)およびサーバB1(プリプロセッシングブロックを受信するサーバ)も、そのような方法を使用して、プリプロセッシングブロックについての包括的チェック結果を決定し、取得した包括的チェック結果をコンセンサスネットワーク内の他の2つのブロックチェーンノードに送信し得る。

【0093】

他の2つのブロックチェーンノードによって送信されたチェック結果を受信した後に、コンセンサスネットワーク内のブロックチェーンノードにあるサーバは、ブロックチェーンノードに含まれているサービスメモリに受信したチェック結果を記憶し得る。

【0094】

サーバA1は、第2のブロックチェーンノードAに含まれているサービスメモリから、ブロックチェーンノードによって送信された、プリプロセッシングブロックについての包括的チェック結果(サーバA1によって取得された包括的チェック結果を含む)を取得し得る。その後、サーバA1は、包括的チェック結果に基づいてプリプロセッシングブロックがコンセンサスネットワークにおけるサービスコンセンサスに成功したかどうかを決定し得る。yesの場合には、サーバA1は、プリプロセッシングブロックに含まれている各サービスリクエストを第2のブロックチェーンノードAのブロックチェーンに書き込み、noの場合には、サーバA1は、各サービスリクエストをブロックチェーンに書き込まない。同様に、サーバ#3およびサーバB1も、そのような方法を使用して、サーバ#3およびサーバB1が属するブロックチェーンノードに含まれているサービスメモリから包括的チェック結果を取得し、取得した包括的チェック結果に基づいて、プリプロセッシングブロックに含まれている各サービスリクエストをサーバ#3およびサーバB1のブロックチェーンノードに書き込むかどうかを決定し得る。

【0095】

コンセンサスネットワーク内の各ブロックチェーンノードが複数のサーバを含んでいることを上記で説明した方法から理解できよう。したがって、各ブロックチェーンノードにあるサーバのうちの1つはオンライン状態である、換言すれば、利用可能であるならば、ブロックチェーンノードはコンセンサスネットワーク内の利用可能なブロックチェーンノードである、このことが、コンセンサスネットワーク内のブロックチェーンノードの安定性を大幅に改善している。加えて、各ブロックチェーンノードは複数のサーバを含み、サーバの機能および状態はブロックチェーンノードに関して同一である。換言すれば、既存の技術と比較して、等質のサーバがブロックチェーンノードに追加されている。このことがブロックチェーンノードのパフォーマンスを大幅に改善しており、そのため、ブロックチェーンノードのサービス処理効率が大幅に改善される。

【0096】

サービスコンセンサスプロセスでは、コンセンサスネットワーク内の各ブロックチェーンノードは、プリプロセッシングブロックについてのブロックチェーンノードによって取得されたチェック結果を決定し、取得したチェック結果をコンセンサスネットワーク内の他のブロックチェーンノードに送信し、ブロックチェーンノードに対応するサービスメモリにチェック結果を記憶し得ることに留意されたい。ブロックチェーンノードは、ブロックチェーンノードに含まれている第1のサーバを使用してコンセンサスチェックをプリプロセッシングブロックに対して行い得るし、第1のサーバは、ブロックチェーンノードにある指定のサーバであり得る、または、ブロックチェーンノードに含まれているサーバから選択されたサーバであり得る。

【0097】

加えて、ブロックチェーンノードはまた、プリプロセッシングブロックについてのコンセンサスネットワーク内の他のブロックチェーンノードによって送信されたチェック結果を受信し得る。ブロックチェーンノードは、ブロックチェーンノードに含まれているサーバを使用して、他のブロックチェーンノードによって送信されたチェック結果を受信し、ブロックチェーンノードに対応するサービスメモリに受信したチェック結果を記憶し得る。ここで、他のブロックチェーンノードによって送信されたチェック結果を受信するサーバを第2のサーバと称し得る。第2のサーバは、ブロックチェーンノードにある任意のサーバであり得るし、当然のことながら、上記で説明した第1のサーバであり得る。他のブロックチェーンノードによって送信されたチェック結果を受信することになるのがどの第2のサーバであるかは、他のブロックチェーンによって送信されたチェック結果を受信するために他のブロックチェーンノードに含まれているサーバによって選択された第2のサーバ次第である。

【0098】

ステップS101においては、第1のブロックチェーンノードにあるサーバの記憶されているアドレスからアドレスをランダムに選択することに加えて、クライアントも、ロードバランシング状態に基づいてアドレスを選択し得る。したがって、第1のブロックチェーンノードにあるサーバのアドレスをクライアントにプッシュする際には、登録センタは、クライアントが所定のロードバランシングアルゴリズムを使用してアドレスから軽負荷のサーバのアドレスを選択し、サービスリクエストをアドレスに対応するサーバに送信するように、サーバの負荷状態をクライアントに連帯してプッシュし得る。

【0099】

同様に、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信する場合には、第1のブロックチェーンノードにあるサーバも、ロードバランシング方法に基づいて記憶されているアドレスからサーバを選択し得る。当然のことながら、第1のブロックチェーンノードにあるサーバも、ロードバランシング方法に基づいてプリプロセッシングブロックを送信し得るし、コンセンサスネットワーク内の各ブロックチェーンノードも、ロードバランシング方法に基づいてチェック結果および包括的チェック結果を送信し得る。具体的なプロセスは、ロードバランシング方法に基づいてクライアントによってサービスリクエストを第1のブロックチェーンノードに送信する方法と同一であるため、詳細はここでは省略する。

【0100】

本出願の本実施形態においては、予定されていたタスクトリガを使用してサービスコンセンサスを開始するサーバを選択することに加えて、コンセンサス期間は、ブロックチェーンノード(第1のブロックチェーンノードおよび第2のブロックチェーンノードを含む)にあるサーバにさらにそれぞれ設定され得るし、異なるサーバは、異なるコンセンサス期間を有している。現在の時間がサーバのコンセンサス期間に達したと決定すると、サーバは、サーバが属するブロックチェーンノードにあるサービスメモリから少なくとも1つのサービスリクエストを取得し得る。

【0101】

本出願の本実施形態においては、ブロックチェーンノード(第1のブロックチェーンノードおよび第2のブロックチェーンノードを含む)にあるサーバも、サービスリクエストを受信した後に、サービスリクエストをブロックチェーンノードにある他のサーバに転送し得るし、他のサーバは、ブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶する。第1のブロックチェーンノードによって送信されたプリプロセッシングブロックを受信した後に、コンセンサスネットワーク内の第2のブロックチェーンノードの各々におけるサーバも、コンセンサスチェックのためにプリプロセッシングブロックを第2のブロックチェーンノードにある他のサーバに転送し得るし、第2のブロックチェーンノードに含まれているサービスメモリに取得したチェック結果を記憶する。

【0102】

本出願の実施形態によるサービスコンセンサス方法を上記で説明している。同じ考えに基づいて、本出願の実施形態は、図6から図12に示した、以下のサービス処理デバイスおよびサービスコンセンサスデバイスをさらに提供している。

【0103】

図6は、本出願の実施形態による、サービス処理デバイスを図示している概略構造図であり、特に、クライアントによって送信されたサービスリクエストを受信するように構成される、受信モジュール601と、デバイスに対応するサービスメモリにサービスリクエストを記憶するように構成される、記憶モジュール602と、第2のブロックチェーンノードの各々がサービスリクエストを受信した後に第2のブロックチェーンノードに含まれているサービスメモリにサービスリクエストを記憶するように、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するように構成される、送信モジュール603であって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、送信モジュール603とを含む。

【0104】

デバイスは、登録センタがアドレスをクライアントおよびコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するように、デバイスがオンラインであると決定されると、デバイスのアドレスを登録センタに送信するように構成される、登録モジュール604をさらに含む。

【0105】

デバイスは、登録センタから第2のブロックチェーンノードの各々に含まれている複数のサーバのアドレスを取得するように構成される、獲得モジュール605をさらに含む。

【0106】

送信モジュール603は、第2のブロックチェーンノードの各々に含まれている複数のサーバの取得したアドレスからアドレスを選択し、サービスリクエストを選択したアドレスに対応するサーバに送信するように特に構成される。

【0107】

記憶モジュール602は、有効検証をサービスリクエストに対して行い、サービスリクエストが有効検証に成功したと決定されると、サービスメモリにサービスリクエストを記憶するように特に構成される。

【0108】

記憶モジュール602は、サービスリクエストが有効検証に成功しなかったと決定されると、サービスリクエストを記憶することをスキップするようにさらに構成される。

【0109】

ブロックチェーンノードは複数のデバイスを含む。

【0110】

図7は、本出願の実施形態による、サービス処理デバイスを図示している概略構造図であり、特に、第1のブロックチェーンノードによって送信されたサービスリクエストを受信するように構成される、リクエスト受信モジュール701であって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、リクエスト受信モジュール701と、デバイスに対応するサービスメモリにサービスリクエストを記憶するように構成される、リクエスト記憶モジュール702とを含む。

【0111】

デバイスは、登録センタがアドレスを第1のブロックチェーンノード、クライアント、およびコンセンサスネットワーク内の他の第2のブロックチェーンノードに送信するように、デバイスがオンラインであると決定されると、デバイスのアドレスを登録センタに送信するように構成される、登録モジュール703をさらに含む。

【0112】

リクエスト記憶モジュール702は、有効検証をサービスリクエストに対して行い、サービスリクエストが有効検証に成功したと決定されると、サービスメモリにサービスリクエストを記憶するように特に構成される。

【0113】

リクエスト記憶モジュール702は、サービスリクエストが有効検証に成功しなかったと決定されると、サービスリクエストを記憶することをスキップするようにさらに構成される。

【0114】

図8は、本出願の実施形態による、サービス処理デバイスを図示している概略構造図であり、特に、ユーザによって入力されたサービス情報を受信するように構成される、情報受信モジュール801と、サービス情報に基づいて対応するサービスリクエストを生成するように構成される、リクエスト生成モジュール802と、第1のブロックチェーンノードが第1のブロックチェーンノードに含まれているサービスメモリに受信したサービスリクエストを記憶するように、サービスリクエストを第1のブロックチェーンノードに含まれているサーバに送信し、サービスリクエストをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信するように構成される、送信モジュール803であって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含み、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、送信モジュール803とを含む。

【0115】

送信モジュール803は、登録センタから第1のブロックチェーンノードに含まれている複数のサーバのアドレスを取得することと、第1のブロックチェーンノードに含まれている複数のサーバの取得したアドレスからアドレスを選択し、サービスリクエストを選択したアドレスに対応するサーバに送信することとをするように特に構成される。

【0116】

デバイスは、サーバに対して登録センタによって送信されたオフライン通知を受信すると、あるサーバのアドレスを削除するように構成される、削除モジュール804をさらに含む。

【0117】

図9は、本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図であり、特に、デバイスに対応するサービスメモリから少なくとも1つのサービスリクエストを取得するように構成される、リクエスト獲得モジュール901と、第2のブロックチェーンノードの各々がサービスコンセンサスをプリプロセッシングブロックに対して行うように、少なくとも1つのサービスリクエストをプリプロセッシングブロックにパッケージし、プリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信する、送信モジュール902であって、第2のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、送信モジュール902とを含む。

【0118】

デバイスは、登録センタから第2のブロックチェーンノードの各々に含まれている複数のサーバのアドレスを取得するように構成される、アドレス獲得モジュール903をさらに含む。

【0119】

送信モジュール902は、第2のブロックチェーンノードの各々に含まれている複数のサーバの取得したアドレスからアドレスを選択し、選択したアドレスに対応するサーバがサービスコンセンサスを受信したプリプロセッシングブロックに対して行うように、プリプロセッシングブロックを選択したアドレスに対応するサーバに送信するように特に構成される。

【0120】

図10は、本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図であり、特に、第1のブロックチェーンノードに含まれている複数のサーバからあるサーバを選択するように構成される、選択モジュール1001であって、第1のブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、選択モジュール1001を含む。

【0121】

選択モジュール1001は、現在の時点でタスクトリガ条件を満足しているかどうかを検出し、タスクトリガ条件を満足していると決定すると、第1のブロックチェーンノードに含まれている複数のサーバからサーバを選択するように特に構成される。

【0122】

図11は、本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図であり、特に、プリプロセッシングブロックを取得するように構成される、獲得モジュール1101と、デバイスに対応するサービスメモリに記憶されている各サービスリクエストに基づいてサービスコンセンサスをプリプロセッシングブロックに対して行うように構成される、コンセンサスモジュール1102とを含む。

【0123】

コンセンサスモジュール1102は、コンセンサスチェックをプリプロセッシングブロックに対して行って、チェック結果を取得し、コンセンサスネットワーク内の他のブロックチェーンノードによって送信された各チェック結果を受信し、デバイスに対応するサービスメモリに各受信したチェック結果を記憶し、サービスメモリから各チェック結果を取得し、取得したチェック結果の各々を使用してサービスコンセンサスをプリプロセッシングブロックに対して行うように特に構成される。

【0124】

図12は、本出願の実施形態による、サービスコンセンサスデバイスを図示している概略構造図であり、特に、コンセンサスネットワーク内の各ブロックチェーンノードに含まれている複数のサーバのアドレスを取得するように構成される、獲得モジュール1201であって、各ブロックチェーンノードは、複数のサーバおよび少なくとも1つのサービスメモリを含む、獲得モジュール1201と、記憶のためにブロックチェーンノードに含まれている複数のサーバの取得したアドレスをコンセンサスネットワーク内の他のブロックチェーンノードおよびクライアントに送信する、送信モジュール1202とを含む。

【0125】

デバイスは、ブロックチェーンノードに含まれている複数のサーバの取得したアドレスに基づいてハートビート検出メッセージをコンセンサスネットワーク内の各ブロックチェーンノードに含まれている複数のサーバに送信し、指定の時間が経過した後に、ハートビート検出メッセージに基づいてブロックチェーンノードに含まれている各サーバによって返信された応答メッセージが受信されなかった場合には、サーバがオフラインであると決定し、サーバの記憶されているアドレスを削除するようにクライアントおよびコンセンサスネットワーク内の他のブロックチェーンノードに命令するように構成される、通知モジュール1203をさらに含む。

【0126】

本出願の実施形態は、サービス処理およびコンセンサスの方法およびデバイスを提供している。方法においては、第1のブロックチェーンノードは複数のサーバを含む。第1のブロックチェーンノードは、クライアントによって送信されたサービスリクエストを受信し、含まれている複数のサーバを使用してサービスリクエストを記憶し、複数のサーバのうちのあるサーバを使用して第1のブロックチェーンノードに含まれているサービスメモリから少なくとも1つのサービスリクエストを取得して、プリプロセッシングブロックを取得し、サーバを使用してプリプロセッシングブロックをコンセンサスネットワーク内の第2のブロックチェーンノードの各々に送信して、第2のブロックチェーンノードの各々を使用してサービスコンセンサスをプリプロセッシングブロックに対して行い得る。第1のブロックチェーンノードに含まれている複数のサーバのうちの1つのサーバが利用可能であるならば、第1のブロックチェーンノードが利用可能であることを保証し得る。したがって、コンセンサスネットワーク内の第1のブロックチェーンノードの安定性が改善される。加えて、第1のブロックチェーンノードに含まれている各サーバは、クライアントを使用してユーザによって送信されたサービスリクエストを受信し得るし、各サーバは、コンセンサスネットワーク内の第2のブロックチェーンノードの各々に対するサービスコンセンサスを開始し得る。したがって、ブロックチェーンサービスのサービス処理効率が大幅に改善される。

【0127】

1990年代においては、技術の改善を、ハードウェア改善(例えば、ダイオード、トランジスタ、またはスイッチなどの回路構造に対する改善)とソフトウェア改善(方法の手順に対する改善)との間で明確に区別し得た。しかしながら、技術の発展に伴い、多くの方法の手順の改善は、ハードウェア回路構造の直接的な改善として扱うことができるようになった。ほぼすべての設計者が、改善した方法の手順をハードウェア回路にプログラムして、対応するハードウェア回路構造を得ている。したがって、ハードウェアエンティティモジュールを使用して方法の手順の改善を実施し得ないとは言えない。例えば、プログラマブルロジックデバイス(PLD)(例えば、フィールドプログラマブルゲートアレイ(FPGA))がそのような集積回路である。プログラマブルロジックデバイスの論理機能は、ユーザによって実行されるコンポーネントプログラミングによって決定される。設計者は、チップ製造業者に専用集積回路チップを設計および製造するように要求することなく、自発的プログラミングを行い、デジタルシステムを単一のPLDに「統合」する。加えて、集積回路チップを手動で製造する代わりに、プログラミングは、プログラム開発中に使用されるソフトウェアコンパイラに類似した、「ロジックコンパイラ」というソフトウェアを使用してほとんどが実施される。コンパイルする前の元のコードはまた、ハードウェア記述言語(HDL)と称する特定のプログラミング言語で書かれ、ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java(登録商標) Hardware Description Language)、Lava、Lola、MyHDL、PALASM、およびRHDL(Ruby Hardware Description Language)などの2つ以上のタイプのHDLが存在する。現時点、VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)およびVeril
ogが最も一般的に使用されている。論理的な方法の手順を実施するハードウェア回路を容易に得ることができるように、方法の手順を、論理的にプログラムし、上記のハードウェア記述言語を使用して集積回路にプログラムする必要があるだけであることも当業者は理解すべきである。

【0128】

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

【0129】

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

【0130】

説明を簡潔にするために、機能を様々なユニットに分割することによって、説明したデバイスを説明している。当然のことながら、本出願を実施する際には、ユニットの機能は、ソフトウェアおよび/またはハードウェアの1つまたは複数の要素において実施され得る。

【0131】

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

【0132】

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

【0133】

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

【0134】

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

【0135】

典型的な設定においては、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入力/出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。

【0136】

メモリは、例えば、リードオンリーメモリ(ROM)またはフラッシュメモリ(フラッシュRAM)などといった、コンピュータ可読媒体に存在する、非持続性メモリ、ランダムアクセスメモリ(RAM)、および/または不揮発性メモリを含み得る。

【0137】

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

【0138】

「含む」、「備える」といった用語、またはそれらの任意の他の類型は、非排他的な包含をカバーすることを意図しており、その結果、多くの要素を含むプロセス、方法、商品、もしくはデバイスが、これらの要素だけでなく、明示的に記載していない他の要素も含む、または、そのようなプロセス、方法、商品、もしくはデバイスに本来備わっている要素をさらに含むことをさらに留意されたい。「・・・を含む」で終わる要素は、さらなる制約がない状態で、要素を含むプロセス、方法、商品、またはデバイスにおける追加の同一要素の存在を除外することはしない。

【0139】

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

【0140】

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

【0141】

本明細書における実施形態はすべて、漸進的方法で説明している。実施形態の同一または同様の部分については、その実施形態を参照されたい。各実施形態は、他の実施形態とは異なる部分に焦点を置いている。特に、システム実施形態は、方法の実施形態と基本的に同様であるため、したがって、簡潔に説明している。関連する部分については、方法の実施形態の説明の一部を参照されたい。

【0142】

上記の説明は、本出願の実施形態であり、本出願を限定することは意図していない。当業者は、本出願に対して様々な修正および変更をなし得る。本出願の精神および原理においてなされた任意の修正、均等物との置換、改良などは、本出願の特許請求の範囲の範囲に含まれるものとする。

【符号の説明】

【0143】

601 受信モジュール
602 記憶モジュール
603 送信モジュール
604 登録モジュール
605 獲得モジュール
701 リクエスト受信モジュール
702 リクエスト記憶モジュール
703 登録モジュール
801 情報受信モジュール
802 リクエスト生成モジュール
803 送信モジュール
804 削除モジュール
901 リクエスト獲得モジュール
902 送信モジュール
903 アドレス獲得モジュール
1001 選択モジュール
1101 獲得モジュール
1102 コンセンサスモジュール
1201 獲得モジュール
1202 送信モジュール
1203 通知モジュール

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】