特許 6883106 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体

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

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

(11)【特許番号】6883106

(24)【登録日】2021年5月11日

(45)【発行日】2021年6月9日

(54)【発明の名称】分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体

(51)【国際特許分類】

   H04L 9/32 20060101AFI20210531BHJP

【ＦＩ】

   H04L9/00 675Z

【請求項の数】35

【全頁数】40

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

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

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

(43)【公表日】2020年4月23日

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

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

(87)【国際公開日】20181004

【審査請求日】2019年6月13日

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

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

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

(73)【特許権者】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】郭 ▲鋭▼

(72)【発明者】

【氏名】李 茂材

(72)【発明者】

【氏名】▲趙▼ ▲チ▼

(72)【発明者】

【氏名】▲張▼ 建俊

(72)【発明者】

【氏名】▲屠▼ ▲海▼涛

(72)【発明者】

【氏名】王 宗友

(72)【発明者】

【氏名】梁 ▲軍▼

(72)【発明者】

【氏名】朱 大▲衛▼

(72)【発明者】

【氏名】▲陳▼ 立生

(72)【発明者】

【氏名】▲劉▼ 斌▲華▼

【審査官】 児玉 崇晶

(56)【参考文献】

【文献】 特表２０１６−５１７６０５（ＪＰ，Ａ）

【文献】 特開２０１５−０５７６９２（ＪＰ，Ａ）

【文献】 米国特許第０８９１８３９２（ＵＳ，Ｂ１）

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

Ｈ０４Ｌ ９／３２

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

【請求項1】

分散システムであって、
クライアントと複数のノードとを備え、
前記ノードは、第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成され、
前記ノードは、マスターノードの状態にある場合に、前記クライアントから送信されたメッセージの電子署名を検証し、前記メッセージを前記スレーブノードへ送信するように構成され、
前記ノードは、マスターノードの状態にある場合に、所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成され、
前記ノードは、さらに、スレーブノードの状態にある場合に、前記マスターノードから送信された前記メッセージを受信したときに前記クライアントへ結果を返信し、前記マスターノードから受信したメッセージの電子署名を検証して、前記マスターノードへ受信確認通知を送信するように構成され、
前記ノードは、スレーブノードの状態にある場合に、前記マスターノードから受信したメッセージ記憶通知の電子署名を検証して、前記マスターノードから受信したメッセージを永続的に記憶するように構成され、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される、
分散システム。

【請求項2】

前記クライアントは、さらに、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージにおける一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定し、結果を返信していないスレーブノードを障害ノードとして決定するように構成される、
請求項１に記載の分散システム。

【請求項3】

前記クライアントは、さらに、受信された結果に含まれた配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、前記マスターノードが悪意のあるノードであると判定するように構成される、
請求項１に記載の分散システム。

【請求項4】

前記クライアントは、さらに、前記マスターノードが悪意のあるノードであると決定し、或いは、前記スレーブノードに障害ノードが存在すると決定した場合に、前記分散システムにおけるノードが第２のコンセンサスモードに切り替えるようにトリガーする、
請求項１に記載の分散システム。

【請求項5】

前記ノードは、さらに、前記第２のコンセンサスモードに切り替える準備段階にある場合に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、対応するノードの電子署名が含まれている一致性確認を前記クライアントへ送信するように構成され、
前記クライアントは、さらに、所定の時間内に全ての前記ノードの一致性確認を受信した場合に、前記分散システムにおけるノードが前記第１のコンセンサスモードに戻るように通知し、前記所定の時間内には全ての前記ノードの一致性確認を受信していない場合に、前記分散システムにおけるノードが継続して前記第２のコンセンサスモードに切り替えるように通知する、
請求項４に記載の分散システム。

【請求項6】

前記ノードは、さらに、前記第２のコンセンサスモードに切り替える準備段階にある場合に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、メッセージの送信ノードへ、対応するノードの電子署名が含まれているデータ確認を送信するように構成され、
前記クライアントは、さらに、所定の時間内には合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、前記分散システムにおけるノードが継続して前記第２のコンセンサスモードに切り替えるようにトリガーする、
請求項４に記載の分散システム。

【請求項7】

前記ノードは、さらに、マスターノードの状態にあるとともに、前記第２のコンセンサスモードにおいてカウントした回数であって、受信したメッセージに関して前記スレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、前記スレーブノードとともに前記第１のコンセンサスモードに切り替えに関して合意形成するように構成される、
請求項４に記載の分散システム。

【請求項8】

前記ノードは、さらに、マスターノードの状態にあるとともに、カウントした回数がマスターノードの合意形成回数の閾値を超えた場合に、前記第１のコンセンサスモードに切り替える旨の通知を前記スレーブノードへ送信し、全ての前記スレーブノードから送信された切替確認を受信した場合に、前記スレーブノードと同期して前記第１のコンセンサスモードに切り替えるように構成される、
請求項７に記載の分散システム。

【請求項9】

前記ノードは、さらに、スレーブノードの状態にあり、前記第１のコンセンサスモードに切り替える旨の通知を受信し、かつ、受信したメッセージに関して合意形成した回数がスレーブノードの合意形成回数の閾値を超えたとカウントした場合に、前記マスターノードへ切替確認を送信するように構成される、
請求項８に記載の分散システム。

【請求項10】

前記ノードは、さらに、前記マスターノードのハートビートを受信していない場合に、或いは、前記マスターノードが悪意のあるノードである場合に、投票操作を再実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される、
請求項１に記載の分散システム。

【請求項11】

前記ノードは、さらに、新しいコンセンサス周期が到来し、かついずれのノードから送信されたハートビートも受信していない場合に、前記分散システムにおけるノードへ投票要求を送信し、所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換して前記分散システムにおけるノードへハートビートを定期的に送信するように構成され、
投票確認は、前記分散システムにおけるノードが送信され、かつ送信される前には前記投票要求に含まれた電子署名は検証され、
前記ノードは、さらに、新しいコンセンサス周期が到来し、かつ前記分散システムにおけるノードから送信されたハートビートを受信した場合に、スレーブノードの状態に変換するように構成される、
請求項１に記載の分散システム。

【請求項12】

メッセージ処理方法であって、
第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、分散システムにおけるノードが投票操作を実行し、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されることと、
前記ノードがマスターノードの状態にある場合に、前記ノードは、
クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信する操作と、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信する操作とを実行することと、を含み、
前記スレーブノードが前記メッセージを受信したときに前記クライアントへ返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、
メッセージ処理方法。

【請求項13】

前記ノードがスレーブノードの状態にある場合に、前記ノードは、
前記マスターノードから送信されたメッセージを受信し、前記クライアントへ結果を返信して、受信されたメッセージの電子署名を検証した後に前記マスターノードへ受信確認通知を送信する操作と、
受信されたメッセージ記憶通知の電子署名を検証した後、受信されたメッセージを永続的に記憶する操作とを実行すること、をさらに含む、
請求項１２に記載のメッセージ処理方法。

【請求項14】

前記ノードがスレーブノードの状態にある場合に、前記スレーブノードが前記クライアントへ返信した結果に、前記メッセージの一意のフィールド、前記スレーブノードの電子署名の情報が含まれ、
前記結果は、前記クライアントが含まれた電子署名を検証し、前記結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定するために用いられる、
請求項１２に記載のメッセージ処理方法。

【請求項15】

前記ノードがスレーブノードの状態にある場合に、前記スレーブノードの返信した結果に、前記スレーブノードの受信したメッセージの配列番号が含まれ、
前記結果は、前記クライアントが含まれた配列番号と送信されたメッセージの配列番号とを比較し、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、前記マスターノードが悪意のあるノードであると決定するために用いられる、
請求項１２に記載のメッセージ処理方法。

【請求項16】

前記クライアントは、前記マスターノードが悪意のあるノードであると決定し、或いは、前記スレーブノードに障害ノードが存在すると決定した場合に、前記ノードは、前記クライアントのトリガーに応えて第２のコンセンサスモードに切り替えること、をさらに含む、
請求項１２に記載のメッセージ処理方法。

【請求項17】

前記ノードが前記第２のコンセンサスモードに切り替える準備段階にある場合に、前記ノードは、
前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、前記クライアントへ、対応するノードの電子署名が含まれている一致性確認を送信する操作と、
前記クライアントが所定の時間内に全ての前記ノードの一致性確認を受信した場合に、前記ノードは、前記クライアントの通知に応えて、継続して前記第１のコンセンサスモードに切り替える操作と、
前記クライアントが所定の時間内には全ての前記ノードの一致性確認を受信していない場合に、前記ノードは、前記クライアントの通知に応えて、継続して前記第２のコンセンサスモードに切り替える操作とを実行すること、をさらに含む、
請求項１６に記載のメッセージ処理方法。

【請求項18】

前記ノードが前記第２のコンセンサスモードに切り替える準備段階にある場合に、前記ノードは、
前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、メッセージの送信ノードへ、対応するノードの電子署名が含まれているデータ確認を送信する操作と、
所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、前記所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、前記ノードは、前記クライアントのトリガーに応えて、継続して前記第２のコンセンサスモードに切り替える操作とを実行すること、をさらに含む、
請求項１６に記載のメッセージ処理方法。

【請求項19】

前記ノードがマスターノードの状態にあり、かつ前記第２のコンセンサスモードにおいてカウントした回数であって、受信したメッセージに関して前記スレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、前記スレーブノードとともに前記第１のコンセンサスモードに切り替えること、をさらに含む、
請求項１６に記載のメッセージ処理方法。

【請求項20】

前記スレーブノードとともに前記第１のコンセンサスモードに切り替えることは、
前記マスターノードが前記第１のコンセンサスモードに切り替える旨の通知を前記スレーブノードへ送信し、全ての前記スレーブノードから送信された切替確認を受信した場合に、前記スレーブノードと同期して前記第１のコンセンサスモードに切り替えることを含む、
請求項１９に記載のメッセージ処理方法。

【請求項21】

前記ノードがスレーブノードの状態にある場合に、
前記第１のコンセンサスモードに切り替える旨の通知を受信したときに、受信したメッセージに関して合意形成した回数をカウントし、カウントした回数がスレーブノードの合意形成回数の閾値を超えた場合に、前記マスターノードへ切替確認を送信する操作を実行すること、をさらに含む、
請求項２０に記載のメッセージ処理方法。

【請求項22】

前記スレーブノードが前記マスターノードのハートビートを受信していない場合に、或いは、前記マスターノードが悪意のあるノードである場合に、前記分散システムにおけるノードが投票操作を再実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されること、をさらに含む、
請求項１２に記載のメッセージ処理方法。

【請求項23】

新しいコンセンサス周期が到来し、かつハートビートを受信していない場合に、前記ノードは、前記分散システムにおけるノードへ、前記ノードの電子署名が含まれている投票要求を送信し、
所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換し、前記ノードは前記分散システムにおけるノードへハートビートを定期的に送信し、
前記投票確認は、前記分散システムにおけるノードが前記投票要求に含まれた電子署名を検証する後に送信され、
新しいコンセンサス周期が到来し、かつ前記分散システムにおけるノードから送信されたハートビートを受信した場合に、スレーブノードの状態に変換する、
請求項１２に記載のメッセージ処理方法。

【請求項24】

メッセージ処理方法であって、
クライアントは、分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が含まれているメッセージを送信することと、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を含んで、前記分散システムにおけるスレーブノードへ送信されることと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果を受信することと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することと、を含む、
メッセージ処理方法。

【請求項25】

前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することは、
前記クライアントは、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージにおける一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定することを含む、
請求項２４に記載のメッセージ処理方法。

【請求項26】

前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することは、
前記クライアントは、受信された結果に含まれた配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、前記マスターノードが悪意のあるノードであると判定することを含む、
請求項２４に記載のメッセージ処理方法。

【請求項27】

前記クライアントは、前記マスターノードが悪意のあるノードであると決定した場合に、或いは、前記クライアントは、前記スレーブノードに障害ノードが存在すると決定した場合に、前記分散システムのノードが第２のコンセンサスモードに切り替えるようにトリガーすること、をさらに含む、
請求項２４に記載のメッセージ処理方法。

【請求項28】

前記クライアントは、所定の時間内に全ての前記ノードの一致性確認を受信した場合に、全ての前記ノードが第１のコンセンサスモードに戻るように通知することと、
前記クライアントは、所定の時間内には全ての前記ノードの一致性確認を受信していない場合に、全ての前記ノードが継続して前記第２のコンセンサスモードに切り替えるように通知することと、をさらに含み、
前記一致性確認は、前記ノードの電子署名を含んでおり、前記ノードが前記第２のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ、送信される前に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とが一致すると確認する、
請求項２７に記載のメッセージ処理方法。

【請求項29】

所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、前記クライアントは、前記分散システムにおけるノードが継続して前記第２のコンセンサスモードに切り替えるようにトリガーすること、をさらに含み、
前記データ確認は、対応するノードの電子署名を含んでおり、前記ノードが前記第２のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ、送信される前に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおいて永続的に記憶されたメッセージのハッシュ値とが一致すると確認する、
請求項２７に記載のメッセージ処理方法。

【請求項30】

分散システムにおけるノードであって、
第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される投票ユニットと、
前記ノードがマスターノードの状態にある場合に、クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信し、そして、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成されるマスターノードユニットと、を備え、
前記スレーブノードが前記メッセージを受信したときに前記クライアントへ返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、
ノード。

【請求項31】

分散システムにおけるノードであって、１つ又は複数のプロセッサと、メモリと、１つ以上のプログラムとを備え、前記１つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれ一群の命令に対応する１つ以上のユニットを含むことができ、前記１つ又は複数のプロセッサは、命令を実行する際にメッセージ処理方法を実現するように構成され、前記メッセージ処理方法は、
第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、分散システムにおけるノードが投票操作を実行し、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されることと、
前記ノードがマスターノードの状態にある場合に、前記ノードは、
クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信する操作と、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信する操作とを実行することと、を含み、
前記スレーブノードが前記メッセージを受信したときに前記クライアントへ返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、
ノード。

【請求項32】

分散システムにおけるクライアントであって、
分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が含まれているメッセージを送信し、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を含んで、前記分散システムにおけるスレーブノードへ送信され、
前記スレーブノードは、前記メッセージを受信したときに返信した結果を受信する
ように構成される通信ユニットと、
前記スレーブノードが前記メッセージを受信したときに前記クライアントへ返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される検出ユニットと、を備える、
クライアント。

【請求項33】

分散システムにおけるクライアントであって、１つ又は複数のプロセッサと、メモリと、１つ以上のプログラムとを備え、前記１つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれが一群の命令に対応する１つ以上のユニットを含むことができ、前記１つ又は複数のプロセッサは、命令を実行する際にメッセージ処理方法を実現するように構成され、前記メッセージ処理方法は、
クライアントは、分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が含まれているメッセージを送信することと、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を含んで、前記分散システムにおけるスレーブノードへ送信されることと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果を受信することと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することと、を含む、
クライアント。

【請求項34】

プロセッサに、実行可能なプログラムを実行する際に、請求項１２乃至２３のいずれか一項に記載のメッセージ処理方法を実現させるための前記実行可能なプログラムが記憶されている記憶媒体。

【請求項35】

プロセッサに、実行可能なプログラムを実行する際に、請求項２４乃至２９のいずれか一項に記載のメッセージ処理方法を実現させるための前記実行可能なプログラムが記憶されている記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連する出願の参照
本願は、出願番号が２０１７１０２０３４９９．Ｘで、出願日が２０１７年３月３０日である中国特許出願に基づくものであり、該中国特許出願の優先権を主張し、その内容を全て参照により本願に組み込むものとする。

【0002】

本発明は、通信技術に関し、特に、分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体に関する。

【背景技術】

【0003】

分散システムは、現在一般的に利用される計算システムであり、ブロックチェーン、分散型サービスフレーム(例えば、ZooKeeper)など、様々な分野に適用されている。

【0004】

分散システムの動作プロセスにおいて、ノードは、クライアントからの処理すべきメッセージについて合意形成(Consensus)する必要があり、即ち、分散システムの全てのノード又は多くのノードは受信されたメッセージを確認してから、メッセージを同期して記憶／処理する。

【0005】

例えば、分散システムがプライベートブロックチェーン又はコンソーシアムブロックチェーンに適用される場合に、各ノードは、クライアントのコミットした取引履歴に関してコンセンサスアルゴリズムに基づいて合意形成し(即ち、取引履歴の信頼性を確認し)、取引履歴を各ノードが維持するブロックチェーンに記憶して、各ノードに記憶される取引履歴の一致性を保証する。

【0006】

関連技術で実現される分散システムの利用するコンセンサスアルゴリズムは、合意形成効率に重点を置くか、或いは、合意形成のプロセスにおいて一定のフォールトトレランス性能を保証し、フォールトトレランス性能とは、障害ノード又は悪意のあるノードが存在する場合でも、多くのノードが依然として合意形成できることを保証することを意味する。

【0007】

関連技術に提供される合意形成効率を保証するためのコンセンサスアルゴリズムは、障害ノード及び悪意のあるノードを検出できないので、合意形成の信頼性を保証できない。

【発明の概要】

【発明が解決しようとする課題】

【0008】

本発明の実施態様は、分散システムにおけるノードがメッセージに関して信頼できる合意形成を実現できる分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体を提供する。

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

【0009】

本発明の実施態様の技術的構成は、以下のように実現される。

【0010】

第１の態様によれば、本発明の実施態様は、分散システムであって、
クライアントと複数のノードとを備え、
前記ノードは、第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成され、
前記ノードは、マスターノードの状態にある場合に、前記クライアントから送信されたメッセージの電子署名を検証し、前記メッセージを前記スレーブノードへ送信するように構成され、
前記ノードは、マスターノードの状態にある場合に、所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成され、
前記ノードは、さらに、スレーブノードの状態にある場合に、前記マスターノードから送信された前記メッセージを受信したときに前記クライアントへ結果を返信し、前記マスターノードから受信したメッセージの電子署名を検証して、前記マスターノードから受信したメッセージを永続的に記憶するように構成され、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される、分散システムを提供する。

【0011】

第２の態様によれば、本発明の実施態様は、分散システムにおけるノードに適用可能なメッセージ処理方法であって、
第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、分散システムにおけるノード投票操作を実行し、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されることと、
前記ノードがマスターノードの状態にある場合に、前記ノードは、
前記クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信する操作と、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信する操作とを実行することと、を含み、
前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、メッセージ処理方法を提供する。

【0012】

第３の態様によれば、本発明の実施態様は、分散システムにおけるクライアントに適用可能なメッセージ処理方法であって、
クライアント分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信することと、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは前記マスターノードの電子署名を携帯されて、前記分散システムにおけるスレーブノードへ送信することと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果を受信することと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することと、を含む、メッセージ処理方法を提供する。

【0013】

第４の態様によれば、本発明の実施態様は、分散システムに適用可能なノードであって、
第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される投票ユニットと、
前記ノードがマスターノードの状態にある場合に、前記クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信し、そして、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成されるマスターノードユニットと、を備え、
前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、ノードを提供する。

【0014】

第５の態様によれば、本発明の実施態様は、分散システムに適用可能なノードであって、１つ又は複数のプロセッサと、メモリと、１つ以上のプログラムとを備え、前記１つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれが一群の命令に対応する１つ以上のユニットを含むことができ、前記１つ又は複数のプロセッサは、命令を実行する際に、本発明の実施態様に提供されるノードに適用されるメッセージ処理方法を実現するように構成される、ノードを提供する。

【0015】

第６の態様によれば、本発明の実施態様は、分散システムに適用可能なクライアントであって、
分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信し、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を携帯されて、前記分散システムにおけるスレーブノードへ送信し、
前記スレーブノードが前記メッセージを受信したときに返信した結果を受信するように構成される前記通信ユニットと、
前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される検出ユニットと、を備える、クライアントを提供する。

【0016】

第７の態様によれば、本発明の実施態様は、分散システムに適用可能なクライアントであって、１つ又は複数のプロセッサと、メモリと、１つ以上のプログラムとを備え、前記１つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれが一群の命令に対応する１つ以上のユニットを含むことができ、前記１つ又は複数のプロセッサは、命令を実行する際に、本発明の実施態様に提供されるクライアントに適用されるメッセージ処理方法を実現するように構成される、クライアントを提供する。

【0017】

第８の態様によれば、本発明の実施態様は、プロセッサに、実行可能なプログラムを実行する際に、本発明の実施態様に提供されるノードに適用されるメッセージ処理方法を実現させるための前記実行可能な命令が記憶されている記憶媒体を提供する。

【0018】

第９態様によれば、本発明の実施態様は、プロセッサに、実行可能なプログラムを実行する際に、本発明の実施態様に提供されるクライアントに適用されるメッセージ処理方法を実現させるための前記実行可能な命令が記憶されている記憶媒体を提供する。

【発明の効果】

【0019】

本発明の実施態様は、以下のような有益な効果を有する。
１)電子署名の方式を用いることで分散システムにおける通信の信頼性を保証し、任意の通信を行う双方はそれぞれ電子署名の方式を利用し、即ち、メッセージを送信する際にメッセージの電子署名を携帯させ、電子署名を検証することでメッセージの信頼性を保証する。
２)スレーブノードは、マスターノードから送信されたメッセージを受信するとき、結果を直接クライアントへ返信し、結果に、例えば、一意のフィールド、メッセージの配列番号及び電子署名等の必要な情報が携帯され、これにより、クライアントは、直接スレーブノードから返信された結果に基づいてスレーブノードの合意達成状況を判定でき、異常ノードを高効率に検出する。

【図面の簡単な説明】

【0020】

【図1】本発明の実施形態に提供される分散システム１００がブロックチェーンシステムに適用される１つの任意的な構造模式図である。

【図2】本発明の実施形態に提供されるブロック構造の１つの任意的な模式図である。

【図3A】本発明の実施形態に提供されるノード２００の１つの任意的なソフトウェア・ハードウェア構造模式図である。

【図3B】本発明の実施形態に提供されるクライアント３００の１つの任意的なソフトウェア・ハードウェア構造模式図である。

【図4】本発明の実施形態に提供される第１のコンセンサスモードにおいて各ノードが投票操作を実行することでマスターノード及びスレーブノードを決定する１つの任意的な模式図である。

【図5】本発明の実施形態に提供される分散システムのノードが第１のコンセンサスモードにおいて合意形成し、障害ノード及び悪意のあるノードを検出する１つの任意的なフロー模式図である。

【図6】本発明の実施形態に提供される分散システムが第１のコンセンサスモードと第２のコンセンサスモード間を切り替える１つの任意的なフロー模式図である。

【図7】本発明の実施形態に提供される分散システムが第１のコンセンサスモードと第２のモード間を切り替える１つの任意的なフロー模式図である。

【図8】発明の実施形態に提供されるブロックチェーンシステムがＲＡＦＴアルゴリズムを利用して合意形成する１つの任意的なフロー模式図である。

【図9】発明の実施形態に提供されるブロックチェーンシステムがＰＢＦＴアルゴリズムを利用して合意形成する１つの任意的なフロー模式図である。

【図10】本発明の実施形態に提供される自己適応型コンセンサスアルゴリズムを実現する運転状態図である。

【図11】本発明の実施形態に提供されるＴ−ＲＡＦＴアルゴリズムによる合意形成の実現模式図である。

【図12】本発明の実施形態に提供されるＰＢＦＴアルゴリズムへの切替準備段階においてＴ−ＲＡＦＴアルゴリズムに戻る１つの任意的なフロー模式図である。

【図13】本発明の実施形態に提供されるブロックチェーンシステムがＴ−ＲＡＦＴアルゴリズムによる合意形成からＰＢＦＴアルゴリズムによる合意形成に切り替える１つの任意的なフロー模式図である。

【図14】本発明の実施形態に提供されるブロックチェーンシステムがＰＢＦＴアルゴリズムのコンセンサスモードからＴ−ＲＡＦＴアルゴリズムのコンセンサスモードに切り替える１つの任意的なフロー模式図である。

【図15】本発明の実施形態に提供される分散システムがコンソーシアムチェーンシステムに適用される１つの任意的なシーン模式図である。

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

【0021】

以下、図面及び実施形態を結合して本発明をさらに詳しく説明する。ここで提供される実施形態はあくまでも本発明を解釈するためのものであり、本発明を限定することを意図していないことは、理解されるべきである。また、衝突しない限り、本発明の実施形態に記載された技術的構成を任意に組み合わせて実施されることができる。

【0022】

１)分散システム：複数のノードとクライアントとがネットワークを介して通信し接続されて形成されるシステムであり、ネットワーク通信に使用されるメッセージの内容は実際の業務シーンによって異なり、例えば、メッセージは、取引履歴、ノードのステートマシンが実行するための命令等であることができる。

【0023】

２)コンセンサス：分散システムにおいて、ノードは他のノード(即ち、分散システムにおけるメッセージを送信したノードを除いた任意のノード)から送信されたメッセージの正確性を検証し、検証が成功していれば、メッセージの送信ノードへ確認を送信し、このメッセージを永続的に記憶して、後続の問い合わせをサポートするために用いる。

【0024】

例えば、分散システムがブロックチェーンシステムとして実施される場合に、ノードは、他のノードのコミットした新しいブロック(新たに発生した取引履歴を含む)の有効性を検証し、検証が成功していれば、新しいブロックを送信したノードへ確認を送信し、この新しいブロックを、対応するノードに記憶されたブロックチェーンの末尾に追加して、ブロックチェーンにおける取引履歴の合意形成を完成する。

【0025】

３)コンセンサスモード：コンセンサスアルゴリズムとも呼ばれ、分散システムのノードが合意形成することを保証するためのアルゴリズムであり、コンセンサスモードは、以下のタイプを含むことができる。

【0026】

第１のコンセンサスモード：高い合意形成効率を実現できるとともに、ノードの障害又はビザンチン問題(一方が他方へメッセージを送信したが、他方が受信していないか、或いは、誤った情報を受信している場合)を検出できるが、しかし、ビザンチン問題を解決できないコンセンサスモードであり、一例として、第１のコンセンサスモードを実現するアルゴリズムは、Paxosアルゴリズム及び再帰のフォールトトレランスアルゴリズム(ＲＡＦＴ、Recursive Algorithm for Fault Tolerance)を含む。

【0027】

第２のコンセンサスモード：ビザンチン問題を解決するためのコンセンサスモードであり、第２のコンセンサスモードを実現するアルゴリズムは、ビザンチンフォールトトレランス(ＢＦＴ、Byzantine Fault Tolerance)アルゴリズム、実用的ビザンチンフォールトトレランス(ＰＢＦＴ、Practical Byzantine Fault Tolerance)アルゴリズム、再帰のフォールトトレランスアルゴリズム−ビザンチンフォールトトレランス(ＢＦＴ−ＲＡＦＴ、Byzantine Fault Tolerance Recursive Algorithm for Fault Tolerance)、ビザンチンフォールトトレランス(ＢＦＴ−Paxos)アルゴリズム等を含む。

【0028】

４)コンセンサスモードの切替：コンセンサスモードの適応とも呼ばれ、分散ネットワークに使用されるコンセンサスアルゴリズムは、ネットワーク環境が良好である場合に、合意形成効率が高くて異常ノード(例えば、ビザンチン問題のあるノード)を検出できるアルゴリズムを自動的に利用して、第１のコンセンサスモードを実現するが、悪意のあるノード又はノードが誤っていることが判明した場合に、ビザンチンフォールトトレランスの問題を解決できるアルゴリズムに自動的に切り替えて第２のコンセンサスモードを実現する。

【0029】

本発明の実施形態を実現する分散システムは、クライアント、複数のノード(ネットワークにアクセスする任意の形態の計算機器、例えば、サーバ、ユーザ端末)がネットワークを介して通信する形で接続されてなり、以下、クライアント及びノードの機能について説明する。

【0030】

ノードは、第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される。

【0031】

ノードは、マスターノードの状態にある場合に、クライアントから送信されたメッセージの電子署名を検証して、メッセージをスレーブノードへ送信するように構成される。

【0032】

ノードは、マスターノードの状態にある場合に、所定数を超えたスレーブノードの受信確認通知を受信し、受信確認通知の電子署名を検証した後にメッセージを永続的に記憶して、スレーブノードへメッセージ記憶通知を送信するように構成される。

【0033】

ノードは、さらに、スレーブノードの状態にある場合に、マスターノードから送信されたメッセージを受信したときにクライアントへ結果を返信し、マスターノードから受信したメッセージの電子署名を検証して、マスターノードへ受信確認通知を送信するように構成される。

【0034】

ノードは、スレーブノードの状態にある場合に、マスターノードから受信したメッセージ記憶通知の電子署名を検証して、マスターノードから受信したメッセージを永続的に記憶するように構成される。

【0035】

クライアントは、スレーブノードがメッセージを受信したときに返信した結果に基づいて、分散システムにおける異常ノードを決定するように構成される。

【0036】

一実施形態において、クライアントは、さらに、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定し、結果を返信していないスレーブノードを障害ノードとして決定するように構成される。

【0037】

一実施形態において、クライアントは、さらに、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、マスターノードが悪意のあるノードであると判定するように構成される。

【0038】

一実施形態において、クライアントは、さらに、マスターノードが悪意のあるノードであると決定し、或いは、スレーブノードに障害ノードが存在すると決定した場合に、分散システムにおけるノードが第２のコンセンサスモードに切り替えるようにトリガーする。

【0039】

一実施形態において、ノードは、さらに、第２のコンセンサスモードに切り替える準備段階にあるときに、ノードに永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、対応するノードの電子署名が携帯されている一致性確認をクライアントへ送信するように構成される。

【0040】

クライアントは、さらに、所定の時間内に全てのノードの一致性確認を受信した場合に、分散システムにおけるノードが第１のコンセンサスモードに戻るように通知し、所定の時間内には全てのノードの一致性確認を受信していない場合に、分散システムにおけるノードが継続して第２のコンセンサスモードに切り替えるように通知する。

【0041】

一実施形態において、ノードは、さらに、第２のコンセンサスモードに切り替える準備段階にあるときに、ノードに永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、対応するノードの電子署名が携帯されているデータ確認を、メッセージの送信ノードへ送信するように構成される。

【0042】

クライアントは、さらに、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、分散システムにおけるノードが継続して第２のコンセンサスモードに切り替えるようにトリガーする。

【0043】

一実施形態において、ノードは、さらに、マスターノードの状態にあるとともに、第２のコンセンサスモードにおいて統計した回数であって、受信したメッセージに関してスレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、スレーブノードとともに第１のコンセンサスモードに切り替るように構成される。

【0044】

一実施形態において、ノードは、さらに、マスターノードの状態にあるとともに、統計した回数がマスターノードの合意形成回数の閾値を超えた場合に、第１のコンセンサスモードに切り替える旨の通知をスレーブノードへ送信し、全てのスレーブノードから送信された切替確認を受信した場合に、スレーブノードと同期して第１のコンセンサスモードに切り替えるように構成される。

【0045】

一実施形態において、ノードは、さらに、スレーブノードの状態にあり、第１のコンセンサスモードに切り替える旨の通知を受信し、かつ、受信したメッセージに関して合意形成した回数がスレーブノードの合意形成回数の閾値を超えると統計した場合に、マスターノードへ切替確認を送信するように構成される。

【0046】

一実施形態において、ノードは、さらに、マスターノードの心拍情報を受信していない場合に、或いは、マスターノードが悪意のあるノードである場合に、投票操作を再実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される。

【0047】

一実施形態において、ノードは、さらに、新しいコンセンサス周期が到来し、かついずれものノードから送信された心拍情報も受信していない場合に、分散システムにおけるノードへ投票要求を送信し、所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換して心拍情報を分散システムにおけるノードへ定期的に送信するように構成される。

【0048】

投票確認は、分散システムにおけるノードが送信され、かつ送信される前には投票要求に携帯された電子署名は検証される。

【0049】

一実施形態において、ノードは、さらに、新しいコンセンサス周期が到来し、かつ分散システムにおけるノードから送信された心拍情報を受信した場合に、スレーブノードの状態に変換するように構成される。

【0050】

以下、分散システムがブロックチェーンシステムとして実施されることを例として説明し、図１を参照すると、図１は、本発明の実施形態に提供される分散システム１００がブロックチェーンシステムとして実施される１つの任意的な構造模式図であり、複数のノード２００(ネットワークにアクセスする任意の形態の計算機器であり、例えば、サーバ、ユーザ端末)からなり、クライアント３００をさらに備え、ノード２００間でピアツーピア(Ｐ２Ｐ、Peer To Peer)ネットワークが形成され、Ｐ２Ｐプロトコルは、伝送制御プロトコル(ＴＣＰ、Transmission Control Protocol)にて実行されるアプリケーション層プロトコルである。

【0051】

図１に示されるブロックチェーンシステムにおけるノード２００の機能を参照し、かかる機能は、以下を含む。

【0052】

１)ルーター：ノードが有する基本的な機能であり、ノード間の通信をサポートする。
ノード２００は、ルーター機能を有するほか、以下の機能をさらに有してもよい。

【0053】

２)アプリケーション：ブロックチェーンに配置され、実際の業務需要に応じて特定の業務を実現し、機能の実現に関するデータを記録して記録データを形成し、記録データには、ジョブデータの由来を表す電子署名が携帯されており、記録データをブロックチェーンシステムにおける他のノード(即ち、ブロックチェーンシステムにおける記録データを受信した任意のノード)へ送信し、これにより、他のノードが記録データの由来及び完全性の検証に成功したときに、記録データをテンポラリブロックに追加する。

【0054】

例えば、アプリケーションで実現される業務は、以下を含む。

【0055】

２．１)ウォレット：電子マネーでの取引を行う機能を提供し、取引を開始することを含み、即ち、現在行われている取引の取引履歴をブロックチェーンシステムにおける他のノードへ送信し、他のノードによる検証が成功した後、取引が有効であることを承認する応答として、取引が成立した記録データをブロックチェーンのテンポラリブロックに保存する。もちろん、ウォレットは、電子マネーアドレスにおける残りの電子マネーを問い合わせることをもサポートする。

【0056】

２．２)共有元帳：会計データの記憶、問い合わせおよび修正等の操作の機能を提供し、会計データに対する操作の記録データをブロックチェーンシステムにおける他のノードへ送信し、他のノードによって有効であると検証された後、会計データが有効であることを承認する応答として、記録データをテンポラリブロックに保存する。さらに、操作を発したノードへ確認を送信してもよい。

【0057】

２．３)スマートコントラクト：コンピュータ化されたプロトコルであり、ある契約の条項を実行でき、共有元帳に配置された、一定の条件を満たすときに実行されるコードによって実現され、実際の業務需要に応じて、コードは取引を自動的に完成し、例えば、バイヤが購入した商品の物流状態を問い合わせ、バイヤが受け取りサインをした後、バイヤの電子マネーをベンダーのアドレスに移動させる。もちろん、スマートコントラクトは、取引を実行するための契約に限らず、受信した情報の処理を実行する契約であってもよい。

【0058】

３)ブロックチェーン：生成順に相互に繋がる一連のブロック(Block)を含み、新しいブロックがブロックチェーンに追加されると、削除されることはなく、ブロックに、ブロックチェーンシステムにおけるノードのコミットした記録データは記録されている。

【0059】

一例として、図２を参照すると、図２は、本発明の実施形態に提供されるブロック構造(Block Structure)の１つの任意的な模式図であり、各ブロックには、本ブロックに記憶された取引履歴のハッシュ値(本ブロックのハッシュ値)、および前のブロックのハッシュ値が含まれ、各ブロックはハッシュ値によって接続されてブロックチェーンを形成する。また、ブロックには、ブロック生成時のタイムスタンプ等の情報が含まれてもよい。

【0060】

本発明の実施形態を実現する分散システムの構成は、柔軟に変更できるという特徴を有し、例を挙げれば、分散システムにおいて、例えばサーバ、端末など、任意の機器は分散システムに追加されてノードとなることができ、ハードウェア面において、一例として、図３Ａを参照すると、図３Ａは、本発明の実施形態に提供されるノード２００の１つの任意的なソフトウェア・ハードウェア構造模式図であり、ノード２００は、ハードウェア層、駆動層、操作システム層及びアプリケーション層を含む。図３Ａに示されるノード２００の構造は一例に過ぎず、ノード２００の構造を限定していないことは当業者に理解されるべきであり、例えば、ノード２００は、実施のニーズに応じて図３Ａよりも多い構成要素を設けるか、或いは、一部の構成要素を省略してもよい。

【0061】

ノード２００のハードウェア層はプロセッサ２１０、入出力インターフェース２４０、記憶媒体２３０およびネットワークインターフェース２２０を含み、その構成要素はシステムバスを介して接続されて通信できる。

【0062】

プロセッサ２１０は、中央処理装置(ＣＰＵ)、マイクロプロセッサ(ＭＣＵ、Microcontroller Unit)、特定用途向け集積回路(ＡＳＩＣ、Application Specific Integrated Circuit)又はロジックプログラマブルゲートアレイ(ＦＰＧＡ、Field−Programmable Gate Array)を用いて実現されることができる。

【0063】

入出力インターフェース２４０は、例えば表示画面、タッチパネル、スピーカ等の入出力デバイスを用いて実現されることができる。

【0064】

記憶媒体２３０は、フラッシュメモリ、ハードディスク、光ディスク等の不揮発性記憶媒体を用いて実現されることができれば、ダブルデータレート(ＤＤＲ、Double Data Rate)ダイナキャッシュ等の揮発性記憶媒体を用いて実現されることもでき、メッセージ処理方法を実行するための実行可能な命令を記憶している。

【0065】

ネットワークインターフェース２２０は、プロセッサ２１０のために外部データへのアクセス能力、例えば、遠隔地に設けられた記憶媒体２３０へのアクセス能力を提供し、一例として、ネットワークインターフェース２２０は、例えば、符号分割多元接続(ＣＤＭＡ、Code Division Multiple Access)、広帯域符号分割多元接続(ＷＣＤＭＡ（登録商標）、Wideband Code Division Multiple Access)等の通信方式及その進化方式に基づく通信を実現できる。

【0066】

駆動層は、操作システム２６０がハードウェア層を認識し、ハードウェア層の各構成要素と通信するためのミドルウェア２５０を含み、例えば、ハードウェア層の各構成要素に対する駆動プログラムの集まりであることができる。

【0067】

操作システム２６０は、ユーザに向けたグラフィカルインタフェースを提供し、ブロックチェーンに基づく様々なアプリケーション処理の様々な中間結果と最終結果を表示するように構成される。

【0068】

アプリケーション層は、ノード間での合意形成を実現するように構成されるコンセンサスメカニズム２７０(第１のコンセンサスモードと第２のコンセンサスモード間を適応的に切り替えるように構成される)、および、ノードが分散システムに基づいて実現する機能、例えば、電子マネーウォレット２８０、スマートコントラクト２９０等を含み、第１のコンセンサスモードと第２のコンセンサスモードとを含む。

【0069】

アプリケーション層に関して例を挙げれば、図３Ａを参照すると、図３Ａに提供されるノード２００のアプリケーション層のコンセンサスメカニズム２７０は、以下を備える。

【0070】

投票ユニット２７０１：第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、ノード２００及び分散システムにおける他のノードが投票操作を実行することで、マスターノードの状態又はスレーブノードの状態にされるように構成される。

【0071】

マスターノードユニット２７０２：ノード２００がマスターノードの状態にある場合に、クライアントのメッセージを受信し、メッセージの電子署名を検証した後にメッセージをスレーブノードへ送信し、そして、所定数を超えたスレーブノードの受信確認通知を受信したとき、確認受信メッセージの電子署名を検証した後にメッセージを永続的に記憶して、メッセージ記憶通知をスレーブノードへ送信するように構成される。

【0072】

スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる。

【0073】

スレーブノードユニット２７０３：ノード２００がスレーブノードの状態にある場合に、受信されたメッセージ記憶通知の電子署名を検証した後、受信されたメッセージを永続的に記憶するように構成され、メッセージは、クライアントが異常ノードを決定するために用いられる。

【0074】

一実施形態において、スレーブノードユニット２７０３は、ノード２００がスレーブノードの状態にある場合に、マスターノードから送信されたメッセージを受信し、結果をクライアントへ返信し、受信されたメッセージの電子署名を検証した後、受信確認通知をマスターノードへ送信し、そして、受信されたメッセージ記憶通知の電子署名を検証した後、受信されたメッセージを永続的に記憶する操作を実行するように構成される。

【0075】

一実施形態において、ノード２００がスレーブノードの状態にある場合に、スレーブノードからクライアントに返信された結果に、メッセージの一意のフィールド、スレーブノードの電子署名の情報が携帯されており、結果は、前記クライアントが携帯された電子署名を検証し、結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定するために用いられる。

【0076】

一実施形態において、ノード２００がスレーブノードの状態にある場合に、スレーブノードから返信された結果に、スレーブノードの受信したメッセージの配列番号が携帯されており、結果に携帯された配列番号は、クライアントが受信された結果に携帯された配列番号と送信されたメッセージの配列番号とを比較し、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、マスターノードが悪意のあるノードであると判定するために用いられる。

【0077】

一実施形態において、切替ユニット２７０４をさらに備え、切替ユニット２７０４は、クライアントが、マスターノードが悪意のあるノードであると決定し、或いは、スレーブノードに障害ノードが存在すると決定した場合に、クライアントのトリガーに応えて第２のコンセンサスモードに切り替えるように構成される。

【0078】

一実施形態において、切替ユニット２７０４は、さらに、ノード２００が第２のコンセンサスモードに切り替える準備段階にあるときに、以下の操作を実行するように構成される。

【0079】

ノード２００に永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノード(即ち、分散システムにおけるノード２００を除いたノード)に永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、一致性確認をクライアントへ送信し、一致性確認に、対応するノードの電子署名が携帯されており、クライアントが一致性確認を受信するときに検証するために用いられる。

【0080】

クライアントが所定の時間内に全てのノードの一致性確認を受信した場合に、クライアントの通知に応えて第１のコンセンサスモードに切り替える。

【0081】

クライアントが所定の時間内には全てのノードの一致性確認を受信していない場合に、クライアントの通知に応えて継続して第２のコンセンサスモードに切り替える。

【0082】

一実施形態において、切替ユニット２７０４は、さらに、ノード２００が第２のコンセンサスモードに切り替える準備段階にあるときに、以下の操作を実行するように構成される。

【0083】

ノードに永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノード(即ち、分散システムにおけるノード２００を除いたノード)に永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、メッセージの送信ノードへデータ確認を送信し、データ確認は、対応するノードの電子署名が携帯されている。

【0084】

データ確認は、クライアントが、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードが他のノードから送信されたデータ確認を受信していない場合に、分散システムのノードが継続して第２のコンセンサスモードに切り替えるようにトリガーするために用いられる。

【0085】

一実施形態において、マスターノードユニット２７０２は、さらに、ノード２００がマスターノードの状態にあるとともに、第２のコンセンサスモードにおいて受信したメッセージに関してスレーブノードと合意形成した回数がマスターノードの合意形成回数の閾値を超えたと統計した場合に、スレーブノードとともに第１のコンセンサスモードに切り替えるように構成される。

【0086】

一実施形態において、マスターノードユニット２７０２は、さらに、第２のコンセンサスモードにおいて統計した回数であって、受信したメッセージに関してスレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、第１のコンセンサスモードに切り替える旨の通知をスレーブノードへ送信し、全てのスレーブノードから送信された切替確認を受信した場合に、スレーブノードと同期して第１のコンセンサスモードに切り替えるように構成される。

【0087】

一実施形態において、スレーブノードユニット２７０３は、さらに、ノードがスレーブノードの状態にある場合に、第１のコンセンサスモードに切り替える旨の通知を受信したときに、受信したメッセージに関して合意形成した回数を統計し、統計した回数がスレーブノードの合意形成回数の閾値を超えた場合に、切替確認をマスターノードへ送信する操作を実行するように構成される。

【0088】

一実施形態において、投票ユニット２７０１は、さらに、マスターノードの心拍情報を受信していない場合に、或いは、マスターノードが悪意のあるノードである場合に、分散システムにおけるノード(即ち、分散システムにおけるノード２００を除いたノード)とともに投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される。

【0089】

一実施形態において、投票ユニット２７０１は、さらに、新しいコンセンサス周期が到来し、かつ分散システムにおけるノードから送信された心拍情報を受信していない場合に、分散システムにおけるノードへ投票要求を送信し、投票要求に、ノードの電子署名が携帯されており、所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換し、心拍情報を分散システムにおけるノードへ定期的に送信することで、マスターノードの状態を保持するように構成され、投票確認は、分散システムにおけるノードが投票要求に携帯された電子署名を検証した後に送信される。

【0090】

投票ユニット２７０１は、さらに、新しいコンセンサス周期が到来し、かつ分散システムにおけるノードから送信された心拍情報を受信した場合に、スレーブノードの状態に変換するように構成される。

【0091】

分散システムにおいて、クライアントは、ハードウェア、及びハードウェアに配置されるソフトウェア環境の組み合わせであることができ、これに基づいて、クライアントはクライアント機器と呼ばれることもでき、マイニング、管理ノード、配置されるスマートコントラクト等の機能を実現するように構成される。

【0092】

図３Ｂを参照すると、図３Ｂは、本発明の実施形態のクライアントの１つの任意的なソフトウェア・ハードウェア構造模式図であり、クライアント３００は、ハードウェア層、駆動層、操作システム層およびアプリケーション層を含む。図３Ｂに示されるクライアント３００の構造は一例に過ぎず、クライアント３００の構造を限定していないことは当業者に理解されるべきである。例えば、クライアント３００は、実施のニーズに応じて図３Ｂよりも多い構成要素を設けるか、或いは、実施のニーズに応じて一部の構成要素を省略してもよい。

【0093】

クライアント３００のハードウェア層は、プロセッサ３１０、入出力インターフェース３４０、記憶媒体３３０およびネットワークインターフェース３２０を含み、その構成要素はシステムバスを介して接続されて通信できる。

【0094】

プロセッサ３１０は、ＣＰＵ、ＭＣＵ、ＡＳＩＣ又はＦＰＧＡを用いて実現されることができる。

【0095】

入出力インターフェース３４０は、例えば表示画面、タッチパネル、スピーカ等の入出力デバイスを用いて実現されることができる。

【0096】

記憶媒体３３０は、フラッシュメモリ、ハードディスク、光ディスク等の不揮発性記憶媒体を用いて実現されることができれば、ＤＤＲを用いて実現されることもでき、上述したメッセージ処理方法を実行するための実行可能な命令を記憶している。

【0097】

ネットワークインターフェース３２０は、プロセッサ３１０のために外部データへのアクセス能力、例えば、遠隔地に設けられた記憶媒体３３０へのアクセス能力を提供し、一例として、ネットワークインターフェース３２０は、例えば、ＣＤＭＡ、ＷＣＤＭＡ（登録商標）等の通信方式及その進化方式に基づく通信を実現できる。

【0098】

駆動層は、システム３６０がハードウェア層を認識し、ハードウェア層の各構成要素と通信するためのミドルウェア３５０を含み、例えば、ハードウェア層の各構成要素に対する駆動プログラムの集まりであることができる。

【0099】

操作システム３６０は、ユーザに向けたグラフィカルインタフェースを提供し、ブロックチェーンに基づく様々なアプリケーション処理の様々な中間結果と最終結果を表示するように構成される。

【0100】

アプリケーション層は、分散システムのノードへメッセージを送信し、各ノードにメッセージに対する合意を達成させてメッセージを永続的に記憶させるように構成され、また、分散システムにおける異常ノードを検出し、ノードがコンセンサスモードを切り替えることをトリガーする。

【0101】

アプリケーション層に関して例を挙げれば、図３Ｂを参照すると、図３Ｂは、クライアント３００のアプリケーション層の機能構造を提供し、管理ノード３８０、配置されるスマートコントラクト３９０およびコンセンサス３７０を含む。

【0102】

コンセンサス３７０に関して例を挙げれば、以下を備える。

【0103】

通信ユニット３７０１：クライアントの電子署名が携帯されているメッセージを分散システムのノードのうちのマスターノードへ送信するように構成される。

【0104】

電子署名は、マスターノードが検証するのに用いられ、受信されたメッセージはマスターノードの電子署名を携帯されて、分散システムにおけるスレーブノードへ送信する。

【0105】

通信ユニット３７０１：スレーブノードがメッセージを受信したときに返信した結果を受信するように構成される。

【0106】

検出ユニット３７０２：スレーブノードがメッセージを受信したときに返信した結果に基づいて、分散システムにおける異常ノードを決定するように構成される。

【0107】

一実施形態において、検出ユニット３７０２は、さらに、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定するように構成される。

【0108】

一実施形態において、検出ユニット３７０２は、さらに、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、マスターノードが悪意のあるノードであると判定するように構成される。

【0109】

一実施形態において、切替ユニット３７０３をさらに備え、切替ユニット３７０３は、マスターノードが悪意のあるノードであると決定した場合に、或いは、スレーブノードに障害ノードが存在すると決定した場合に、分散システムにおけるノードが第２のコンセンサスモードに切り替えることをトリガーする。

【0110】

一実施形態において、切替ユニット３７０３は、さらに、所定の時間内に全てのノードの一致性確認を受信した場合に、全てのノードが第１のコンセンサスモードに戻るように通知し、所定の時間内には全てのノードの一致性確認を受信していない場合に、全てのノードが継続して第２のコンセンサスモードに切り替えるように通知する。

【0111】

前記一致性確認に、前記ノードの電子署名が携帯されており、前記ノードが前記第２のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ送信される前に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とが一致すると確認する。

【0112】

一実施形態において、切替ユニット３７０３は、さらに、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードが他のノードから送信されたデータ確認を受信していない場合に、分散システムにおけるノードが継続して第２のコンセンサスモードに切り替えることをトリガーする。

【0113】

データ確認は、対応するノードの電子署名を携帯しており、ノード２００が前記第２のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ送信される前に、ノード２００に永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノード(即ち、分散システムにおけるノード２００を除いたノード)に永続的に記憶されたメッセージのハッシュ値とが一致すると確認する。

【0114】

本発明の実施形態に提供される分散システムの場合、ノードは、第１のコンセンサスモードを用いてクライアントからのメッセージに関して合意形成し、第１のコンセンサスモードは、ノードの合意形成効率を保証でき、もちろん、本発明の実施形態では、分散システムのノードがデフォルトに第２のコンセンサスモードを用いてクライアントからのメッセージに関して合意形成することは排除されない。

【0115】

第１のコンセンサスモードにおいて合意形成する実現形態に関して説明し、図５を参照すると、図５は、本発明の実施形態に提供される分散システムのノードが第１のコンセンサスモードにおいて合意を達成し、障害ノードおよび悪意のあるノードを検出する１つの任意的なフロー模式図であり、ステップ１０１〜ステップ１０８を結合して説明する。

【0116】

ステップ１０１：分散システムの複数のノードは、第１のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあること、及びスレーブノードの状態にあることが決定される。

【0117】

一実施形態において、分散システムのノードは、競合ノード、マスターノード及びスレーブノードという３つのタイプ(状態とも呼ばれる)を有する。分散システムの各ノードはタイマーをスタートし、合意形成するための新しいコンセンサス周期が到来した場合に、各ノードはいずれも競合ノードであり、各競合ノードは、投票操作を実行することで、マスターノード(１つの分散システムにおいて、正規なマスターノードが１つしかない)に変換しようと努力し、マスターノードになっていない競合ノードはスレーブノードに変換する。

【0118】

各競合ノードは、新しいコンセンサス周期が開始するときに、他のノードから送信された心拍情報を受信したか否かを検出し、受信していなければ、現在のコンセンサス周期内にはまだマスターノードが発生していないことが分かり、この競合ノードは、他のノードへ投票要求を送信し、投票要求に送信ノードの電子署名が携帯され、受信ノードは、投票要求の電子署名の検証に成功した後、投票要求の信頼性を決定し、即ち、送信ノードへ投票確認を送信し、１つのノードが他のノードの投票確認を充分に(例えば、所定数は、半数のノードであることができる)受信していれば、マスターノードに変換し、他のノードへ心拍情報を周期的に送信し、心拍情報を受信した競合ノードはスレーブノードに変換する。１つのコンセンサス周期内にいずれのノードも充分な投票確認を受信していなければ、新しいコンセンサス周期が開始し、マスターノード及びスレーブノードが決まるまで投票操作を継続する。

【0119】

第１のコンセンサスモードでＲＡＦＴアルゴリズムを用いることを例として、図４を参照すると、図４は、本発明の実施形態に提供される第１のコンセンサスモードにおいて各ノードが投票操作を実行することでマスターノード及びスレーブノードを決定する１つの任意的な模式図である。

【0120】

分散システムにおいて、任意のノードは任意の時刻でマスターノード、スレーブノード及び競合ノードという３つの状態のうちのいずれかの状態にある。分散システムが通常に運転するほとんどの時間内に、分散システムに１つのマスターノードが存在し、他のノードはいずれもスレーブノードであり、マスターノードがクライアントのメッセージを受信する。

【0121】

分散システムの動作時間は、連続するコンセンサス周期に分けられ、ここで、任期(Term)とも呼ばれ、各任期は、任意の時間長であってもよく、任期は、連続する整数で番号を付けられる。各任期で、まず最初にマスターノード投票を行い、投票段階において、複数の競合ノードがマスターノードとなるように競合し、あるノードがマスターノードになれば、他の競合ノードがスレーブノードに変換し、マスターノードとなったノードは、この任期内にずっとマスターノードを担い、このマスターノードに障害が生じたら、他のノードは新しい任期内に投票を行う。

【0122】

任意の任期でも複数のマスターノードが存在することは不可能であり(悪意のあるノードがマスターノードになりすますことを除く)、個々のノードは現在任期のカウント数を維持し、ノード間で通信を行うたびに、任期のカウント数が含まれ、各ノードは、自分の維持している任期カウント数が他のノードの維持している任期カウント数よりも低いと検出した場合に、自分の任期カウント数が検出された最高値となるように更新する。

【0123】

現在、あるコンセンサス周期におけるマスターノード及び競合ノードは、自分の任期カウント数が他のノードの任期カウント数よりも低いことが判明した場合に、すぐに自分をスレーブノードに変換し、これにより、１つの任期内に１つのマスターノードしかないことを保証する。

【0124】

ＲＡＦＴアルゴリズムでは、心拍メカニズムを用いてマスターノードの投票操作をトリガーし、分散システムが起動する際に、全てのノードがスレーブノード状態に初期化し、任期を０に設定するとともに、タイマーをスタートし、タイマーがタイムアウトした後、スレーブノードが競合ノードに変換し、競合ノードに変換すると、以下の操作を実行する。

【0125】

ステップ１０１１：ノードの任期のカウント数を増やす。

【0126】

ステップ１０１２：新しいタイマーをスタートする。

【0127】

ステップ１０１３：他のノードへ投票要求(Request Vote)遠隔手続き呼出しプロトコル(ＲＰＣ、Remote Procedure Call Protocol)メッセージを送信し、他のノードが投票確認を返信するのを待つ。

【0128】

タイマーがタイムアウトする前に、多くのノードから投票確認を受信していれば、マスターノードに変換する。他のノードから送信された追加内容がアイドルである追加入口(Append Entries)心拍ＲＰＣメッセージを受信していれば、他のノードがマスターノードとして選ばれたことが分かり、スレーブノードに変換する。タイマーがタイムアウトしても上記２つの情報も受信していなければ、新しい投票操作を行う。

【0129】

ノードは、多くのノードの投票を受けてマスターノードになった後、すぐに全てのノードへAppend Entries心拍ＲＰＣメッセージを送信し、競合ノードがAppend Entries心拍ＲＰＣメッセージを受信した後、スレーブノードに変換し、投票操作が終了する。

【0130】

ステップ１０２：クライアントは、メッセージに対して電子署名を行い、電子署名が携帯されているメッセージをマスターノードへ送信する。

【0131】

クライアントは、自分の秘密鍵を用いてメッセージのダイジェスト(本発明の実施形態では、任意のダイジェストアルゴリズムを用いてメッセージからダイジェストを抽出することは排除しない)を暗号化し、電子署名を形成する。

【0132】

ステップ１０３：マスターノードは、メッセージの電子署名の検証に成功した後、メッセージにマスターノードの電子署名を追加して、メッセージをスレーブノードへ送信する。

【0133】

マスターノードは、公開鍵を用いて電子署名を復号してダイジェストを得て、ダイジェストアルゴリズム(クライアントの使用するダイジェストアルゴリズムと一致する)を用いたものと照合し、一致していれば、メッセージの由来が信頼できることが分かり、マスターノードの秘密鍵を用いてメッセージのダイジェストを暗号化してマスターノードの電子署名を形成し、メッセージにマスターノードの電子署名を追加して各スレーブノードへ送信する。メッセージに携帯されたクライアントの電子署名は、携帯されても携帯されなくてもよい。マスターノードが照合した結果、一致していなければ、メッセージを破棄してクライアントに対して再伝送するように要求できる。

【0134】

ステップ１０４：スレーブノードは、マスターノードから送信されたメッセージを受信した後、受信されたメッセージの電子署名を検証し、検証が通過した後、受信確認通知をマスターノードへ送信し、結果をクライアントへ送信する。

【0135】

スレーブノードは、公開鍵を用いて受信されたメッセージの電子署名を復号してダイジェストを得て、ダイジェストアルゴリズム(マスターノードの使用するダイジェストアルゴリズムと一致する)を用いたものと照合し、一致していれば、メッセージの由来が信頼できることが分かり、スレーブノードの秘密鍵を用いて受信確認通知のダイジェストを暗号化してスレーブノードの電子署名を形成し、マスターノードへ返信する。

【0136】

スレーブノードが結果をクライアントへ送信することは、２つの場合を含む。

【0137】

１)現在のコンセンサス周期内において、スレーブノードが、マスターノードから送信されたメッセージを初めて受信していれば、クライアントへ送信する結果は、受信されたメッセージの配列番号と、メッセージの一意のフィールド(メッセージにおけるフィールドであり、他のメッセージのフィールドと区別できる)と、スレーブノードの秘密鍵を用いて結果のダイジェストを暗号化して得た、スレーブノードの結果に対する電子署名と、が含まれている。

【0138】

２)現在のコンセンサス周期内において、スレーブノードがマスターノードから送信されたメッセージを受信したことが初めてではなければ、クライアントへ送信する結果に、メッセージの一意のフィールド(メッセージにおけるフィールドであり、他のメッセージのフィールドと区別できる)と、スレーブノードの秘密鍵を用いて結果のダイジェストを暗号化して得た、スレーブノードの結果に対する電子署名と、が含まれている。

【0139】

ステップ１０５：マスターノードは、受信された受信確認通知に携帯された電子署名を検証し、所定数のスレーブノードから送信された受信確認通知を連続して受信した後、メッセージを永続的に記憶し、メッセージ記憶通知をスレーブノードへ送信する。

【0140】

メッセージ記憶通知に、マスターノードのメッセージ記憶通知に対する電子署名が携帯されており、電子署名は、マスターノードの秘密鍵を用いてメッセージ記憶通知のダイジェストを暗号化して得たものである。

【0141】

永続的な記憶の場合に、マスターノードは、メッセージを不揮発的に記憶し、例えば、ブロックチェーンシステムにおいて、クライアントのコミットした取引履歴を受信したノード(マスターノード)は、取引履歴をブロックチェーンの新しいブロックに記憶する。

【0142】

ステップ１０６：スレーブノードがメッセージ記憶通知を受信し、携帯された電子署名の検証に成功した後、スレーブノードのローカルにメッセージを永続的に記憶し、電子署名が携帯されているメッセージ記憶確認をマスターノードへ送信する。

【0143】

スレーブノードは、公開鍵を用いて、受信されたメッセージ記憶通知の電子署名を復号してダイジェストを得て、ダイジェストアルゴリズム(マスターノードの使用するダイジェストアルゴリズムと一致する)を用いたものと照合し、一致していれば、メッセージ記憶通知の由来が信頼できることが分かり、スレーブノードの秘密鍵を用いてメッセージ記憶確認のダイジェストを暗号化してスレーブノードの電子署名を形成し、電子署名が携帯されているメッセージ記憶確認をマスターノードへ返信する。

【0144】

ステップ１０７：マスターノードは、受信されたメッセージ記憶確認の電子署名を検証し、半数を超えたスレーブノードのメッセージ記憶確認を受信し、電子署名の検証に成功していれば、クライアントへメッセージ記憶確認を送信する。

【0145】

マスターノードからクライアントへ送信されたメッセージ記憶確認は、マスターノードの電子署名を携帯しており、クライアントが、記憶されたメッセージの由来の信頼性を検証するために用いられる。

【0146】

ステップ１０８：クライアントは、マスターノード及びスレーブノードがメッセージを受信したときに返信した結果に基づいて、異常ノードを検証し、マスターノードが悪意のあるノードであるか否かを決定するとともに、スレーブノードに障害ノードが存在するか否かを決定する。

【0147】

一実施形態において、クライアントは、各スレーブノードから返信された結果(各スレーブノードがマスターノードから送信されたメッセージを受信した後に送信される)の電子署名の検証に成功した後、受信された結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致していなければ、一致しない一意のフィールドを送信したスレーブノードをエラーノードとして判定し、結果を返信していないスレーブノードを障害ノードとして判定する。

【0148】

一実施形態において、マスターノードが１つの新しいコンセンサス周期内に新たに発生したマスターノードである場合に、このマスターノードから送信されたメッセージを受信したときに、スレーブノードからクライアントへ送信された結果に、一意のフィールド及び電子署名に加え、受信されたメッセージの配列番号も含まれ、これにより、クライアントは、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が数の閾値を超えた場合に、新たに発生したマスターノードがスレーブノードへ偽造メッセージを送信したことが分かるため、マスターノードが悪意のあるノードであると判定する。

【0149】

上述したステップから分かるように、第１のコンセンサスモードにおいて、
１)電子署名の方式を用いることで通信の信頼性を保証する。

【0150】

任意の通信を行う双方はそれぞれ電子署名の方式を利用し、即ち、送信側はメッセージを送信する際にメッセージの電子署名を携帯させ、例えば、送信側の非対称暗号化アルゴリズムの秘密鍵を用いてメッセージのダイジェストを暗号化し、送信側の電子署名を形成し、受信側は、電子署名を検証することでメッセージの信頼性を保証し、即ち、メッセージの署名について、非対称暗号化アルゴリズムの公開鍵(受信側及び送信側が同じ非対称暗号化アルゴリズムを用いることを保証すれば、受信側は公開鍵を予め取得する)を用いて復号し、復号して得たダイジェストとメッセージから抽出されたダイジェストとを照合し、一致していれば、電子署名の検証が通過し、送信側から送信されたメッセージが信頼できることが分かる。

【0151】

２)スレーブノードは、マスターノードから送信されたメッセージを受信するときに、結果を直接クライアントへ返信し、結果に、例えば一意のフィールド、メッセージ配列番号及び電子署名等の必要な情報が携帯され、このように、クライアントは、直接スレーブノードから返信された結果に基づいてスレーブノードの合意達成状況を判定でき、異常ノードを容易に検出できる。

【0152】

第１のコンセンサスモードにおいて異常ノードを検出した場合に、第１のコンセンサスモードは、ノードの合意形成効率を保証することに適するが、ノードの異常に対するフォールトトレランス性能は限られているため、本発明の実施形態は、分散システムにおいて異常ノードが発生したときに、分散システムが優れたフォールトトレランス性能を有する第２のコンセンサスモードに切り替えるようにするソリューションを提供する。

【0153】

図６を参照すると、図６は、本発明の実施形態に提供される分散システムが第１のコンセンサスモードと第２のモード間を切り替える１つの任意的なフロー模式図であり、ステップ１０９〜ステップ１１２を結合して説明する。

【0154】

ステップ１０９：クライアントは、分散システムに異常ノードが存在すると決定した場合に、分散システムにおけるノードが第２のコンセンサスモードに切り替えることをトリガーする。

【0155】

マスターノードが悪意のあるノードであり、スレーブノードに障害ノードが存在し、或いは、スレーブノードに異常ノードが存在する場合に、クライアントは、分散システムのノードへ、第２のコンセンサスモードに切り替える旨の通知を放送する。

【0156】

ステップ１１０：分散システムのノードは、第２のコンセンサスモードに切り替える準備段階において、対応するノードに永続的に記憶されたメッセージのハッシュ値及び電子署名を他のノードへ送信する。

【0157】

ノード２００を例として、ノード２００は、第２のコンセンサスモードに切り替える準備段階において、ノード２００に永続的に記憶されたメッセージのハッシュ値及び電子署名を分散システムにおけるノード２００を除いたノードへ送信する。

【0158】

ステップ１１１：メッセージの受信ノードは、分散システムにおける他の全てのノード(即ち、受信ノードを除いた全てのノード)から送信されたハッシュ値及び電子署名を全て受信し、ハッシュ値の電子署名の検証に成功した後、そのハッシュ値と受信ノードに永続的に記憶されたメッセージのハッシュ値とを比較し、全てが一致していれば、クライアントへ一致性確認を送信する。

【0159】

例えば、分散システムにおける通知を受信したノード１は、第２のコンセンサスモードに切り替える準備段階において、ノードに永続的に記憶されたメッセージのハッシュ値及び電子署名をノード２−Ｎ(Ｎは、分散システムにおけるノードの数である)へ送信(例えば、放送)し、同時に、ノード１は、ノード２〜ノードＮから送信されたハッシュ値を受信し、ハッシュ値には対応するノードの電子署名が携帯されており、ノード１は電子署名の検証に成功した後、ノード２〜ノードＮから送信されたハッシュ値とノード１に永続的に記憶されたメッセージのハッシュ値とを比較し、全てが一致していれば、ノード１はクライアントへ一致性確認を送信する。

【0160】

ノード２〜ノードＮに関して、ハッシュ値を受信した処理はノード１に類似し、その説明を繰り返さない。

【0161】

ステップ１１２：クライアントは、全てのノードの一致性確認を受信したか否かを検出し、ＹＥＳであれば、分散システムのノードが継続して第１のコンセンサスモードに切り替えるように通知し、ＮＯであれば、分散システムのノードが継続して第２のコンセンサスモードに切り替えるように通知する。

【0162】

クライアントが分散システムにおける全てのノードから送信された一致性確認を受信していれば、その前に異常ノードを検出したのは、ネットワークの変動又は応答メッセージを破棄したことによるものであり、分散システムに異常ノードが存在しないことが分かり、このため、再び第１のコンセンサスモードに切り替え、ノード間での合意形成効率を保証する。

【0163】

クライアントは所定の時間内には分散システムにおける全てのノードから送信された一致性確認を受信していなければ、分散システムに確かに異常ノードが存在することが分かり、分散システムにおけるノードが継続して第２のコンセンサスモードへの切り替えを保持するように通知する。

【0164】

図７を参照すると、図７は、本発明の実施形態に提供される分散システムが第１のコンセンサスモードと第２のモード間を切り替える１つの任意的なフロー模式図であり、以下のステップ１１３〜ステップ１１６を含む。

【0165】

ステップ１１３：クライアントは、分散システムに異常ノードが存在すると決定した場合に、分散システムにおけるノードが第２のコンセンサスモードに切り替えることをトリガーする。

【0166】

マスターノードが悪意のあるノードであり、スレーブノードに障害ノードが存在し、或いは、スレーブノードに異常ノードが存在する場合に、クライアントが分散システムのノードへ第２のコンセンサスモードに切り替える旨の通知を放送する。

【0167】

ステップ１１４：分散システムのノードは、第２のコンセンサスモードに切り替える準備段階において、対応するノードに永続的に記憶されたメッセージのハッシュ値及び電子署名を他のノードへ送信する。

【0168】

ステップ１１５：メッセージの受信ノードが分散システムにおける他のノードから送信されたハッシュ値及び電子署名を受信し、ハッシュ値の電子署名の検証に成功した後、そのハッシュ値と受信ノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致していれば、メッセージの送信ノードへデータ確認を送信する。

【0169】

例えば、分散システムにおける通知を受信したノード１は、第２のコンセンサスモードに切り替える準備段階において、ノードに永続的に記憶されたメッセージのハッシュ値及び電子署名をノード２−Ｎ(Ｎは、分散システムにおけるノードの数である)に送信(例えば、放送)し、同時に、ノード１は、ノード２〜ノードＮから送信されたハッシュ値を受信し、ハッシュ値に、対応するノードの電子署名が携帯されており、ノード１は電子署名の検証に成功した後、ノード２〜ノードＮから送信されたハッシュ値とノード１に永続的に記憶されたメッセージのハッシュ値とを比較し、全てが一致していれば、ノード１は、ノード２〜ノードＮへそれぞれデータ確認を送信する。

【0170】

ノード２〜ノードＮに関して、ハッシュ値を受信した処理はノード１に類似し、その説明を繰り返さない。

【0171】

ステップ１１６：クライアントは、各ノードから送信されたデータ確認に基づいて、分散システムのノードが第１のコンセンサスモードに戻るようにトリガーするか、或いは、分散システムのノードが継続して第２のコンセンサスモードに切り替えるようにトリガーする。

【0172】

分散システムの各ノードにとって、ノードに永続的に記憶されたメッセージのハッシュ値及び送信ノードの電子署名を他のノードへ放送する。ハッシュ値の受信ノードにとって、受信されたハッシュ値の電子署名を検証した後、受信されたハッシュ値と受信ノードに記憶されたメッセージのハッシュ値とを比較し、比較した結果、一致する場合に、対応するハッシュ値の送信ノードへ、２つのノードに記憶されたメッセージが一致することを示すデータ確認を送信する。

【0173】

ここで、２つの場合がある。

【0174】

場合１)：所定の時間内に、データ確認の受信ノードは、いずれも他のノード(受信ノードを除いたノード)から送信されたデータ確認を受信していれば、クライアントへデータ確認を送信でき、クライアントは、データ確認に基づいて、各ノードに記憶されたメッセージが一致すると確認し、継続して第２のコンセンサスモードに切り替える必要がないため、分散システムの各ノードへ第１のコンセンサスモードに戻る旨の通知を送信でき、第２のコンセンサスモードに切り替えるプロセスが終了する。

【0175】

例えば、ノード１はノード２〜ノードＮへハッシュ値を送信し、ハッシュ値にノード１の電子署名が携帯され、ノード２〜ノードＮ−１は、ノード１の電子署名の検証に成功した後、ノード２を例として、ノード２は、ノード２に永続的に記憶されたメッセージのハッシュ値(ブロックチェーンシステムにおけるノードにとって、ブロックチェーンにおける最新のブロックのハッシュ値であることができる)とノード１から送信されたハッシュ値とを比較し、一致していれば、ノード１へデータ確認を送信し、ノード３〜ノードＮ−１に関しての処理はノード２に類似する。

【0176】

仮にノード１はノード２〜ノードＮ−１のデータ確認を受信したが、ノードＮのデータ確認を受信していなければ、クライアントは所定の時間内にはノード１のデータ確認を受信していないため、クライアントは、ノード１のデータが全ての他のノードのデータと一致していないと認め、ノード１〜ノードＮが第２のコンセンサスモードに切り替える操作を継続するように通知する。

【0177】

場合２)：所定の時間内にいずれのノードが他のノードのデータ確認を受信していない場合に、或いは、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していないため、クライアントが他のノードのデータ確認を受信していない場合に、クライアントは、分散システムにおけるノードが継続して第２のコンセンサスモードに切り替えるように通知する。

【0178】

例えば、ノード１はノード２〜ノードＮへハッシュ値を送信し、ハッシュ値にノード１の電子署名が携帯され、ノード２〜ノードＮ−１は、ノード１の電子署名の検証に成功した後、ノード２を例として、ノード２は、ノード２に永続的に記憶されたメッセージのハッシュ値(ブロックチェーンシステムにおけるノードにとって、ブロックチェーンにおける最新のブロックのハッシュ値であることができる)とノード１から送信されたハッシュ値とを比較し、一致していれば、ノード１へデータ確認を送信し、ノード３〜ノードＮ−１に関しての処理はノード２に類似する。

【0179】

仮にノード１は、所定の時間内にノード２〜ノードＮ−１のデータ確認を受信したが、ノードＮのデータ確認を受信していなければ、所定の時間内には他のノードのデータ確認を全て受信していない旨の通知をクライアントへ送信し、クライアントは、ノード１〜ノードＮが第２のコンセンサスモードに切り替える操作を継続するように通知する。

【0180】

さらに、例えば、ノード１はノード２〜ノードＮへハッシュ値を送信し、ハッシュ値にノード１の電子署名が携帯され、ノード２〜ノードＮ−１は、ノード１の電子署名の検証に成功した後、ノード２を例として、ノード２は、ノード２に永続的に記憶されたメッセージのハッシュ値(ブロックチェーンシステムにおけるノードにとって、ブロックチェーンにおける最新のブロックのハッシュ値であることができる)とノード１から送信されたハッシュ値とを比較し、一致していれば、ノード１へデータ確認を送信し、ノード３〜ノードＮ−１に関しての処理は、ノード２に類似する。

【0181】

仮にノード１は、所定の時間内にノード２〜ノードＮ−１のデータ確認を受信したが、ノードＮのデータ確認を受信していなければ、ノード１は他のノード(つまり、分散システムにおけるノード１を除いたノード)のデータ確認を全て受信していない旨の通知をクライアントへ送信し、クライアントは、ノード１〜ノードＮが第２のコンセンサスモードに切り替える操作を継続するように通知する。

【0182】

引き続き、分散システムのノードが第２のコンセンサスモードに切り替え、第２のコンセンサスモードから第１のコンセンサスモードに切り替える方式に関して説明し、第２のコンセンサスモードから第１のコンセンサスモードに戻る方式は、以下のいくつかある。

【0183】

方式１)：マスターノードは、合意形成回数がマスターノードの合意形成回数の閾値を超えたと統計した場合に、スレーブノードが第１のコンセンサスモードに切り替えることをトリガーし、マスターノード及びスレーブノードは、第１のコンセンサスモードに切り替えるときに、第２のコンセンサスモードにおけるノード状態を継承する(即ち、ノードがマスターノード又はスレーブノードである状態は変わらないままである)。

【0184】

分散システムが第２のコンセンサスモードにあるときに、分散システムにおけるマスターノード(ここでのマスターノードは１つのコンセンサス周期に対するものであることは理解されることができる)にとって、マスターノードが第２のコンセンサスモードにおいて、受信したメッセージに関してスレーブノードと合意形成する回数がマスターノードの合意形成回数の閾値を超えた(例えば、Ｍ回であり、Ｍは、分散システムにおけるノードの合意精度に基づいて設定され、一般的には、精度要求が高ければ、所定回数が大きくなり、両者は正の相関関係を有する)と統計していれば、マスターノードとスレーブノードが、クライアントから連続して送られるメッセージに関してよく合意を達成していることが分かり、分散システムのノードの合意形成効率をさらに向上させるために、第１のコンセンサスモードに切り替える旨の通知をスレーブノードへ送信できる。

【0185】

分散システムにおけるスレーブノードは、マスターノードから送信された第１のコンセンサスモードに切り替える旨の通知を受信した後、切替確認をマスターノードへ送信し(マスターノードが第１のコンセンサスモードに切り替えるときにマスターノードの状態を継続して保持することを承認する)、マスターノード及びスレーブノードは現在のノード状態を保持したまま第１のコンセンサスモードに切り替え、このように、第１のコンセンサスモードにおいて悪意のあるノードがマスターノードとなることを回避でき、合意形成効率を確保する。

【0186】

上述の合意したノード数の閾値は、分散システムにおける全てのスレーブノードの数であるか、或いは、分散システムにおいて第１のコンセンサスモードで合意形成することを求められるスレーブノードの数の最小値(即ち、第１のコンセンサスモードのフォールトトレランス性能に求められる合意したノード数の最小値であり、最小値よりも低ければ、第１のコンセンサスモードで達成した合意の信頼性は保証されることができない)であることができる。

【0187】

同様に、上述の合意したノード割合閾値は、分散システムにおける全てのスレーブノードの数に対応し、例えば１００％であるか、或いは、分散システムにおいて第１のコンセンサスモードで合意形成することを求められるスレーブノードの数の最小値、例えば、５１％(即ち、第１のコンセンサスモードのフォールトトレランス性能に求められる合意したノード数の最小値であり、この最小値よりも低ければ、第１のコンセンサスモードで達成した合意の信頼性は保証されることができない)であることができる。

【0188】

例えば、分散システムが第２のコンセンサスメカニズムにあり、仮にノード１をマスターノードとし、ノード２〜ノードＮをスレーブノードとすると、各ノードがクライアントからのメッセージに関して合意形成することをカウントし、ノード１にとって、ノード１とノード２〜ノードＮは、最近クライアントから送られたＭ個(マスターノードの合意形成回数の閾値)のメッセージのそれぞれに関して合意を達成していれば、各ノード間でよく合意を達成したことが示され、ノード１は第１のコンセンサスモードに切り替える旨の通知をノード２〜ノードＮへ送信し、ノード２〜ノードＮはノード１へ切替確認を送信し、ノード１が第１のコンセンサスモードにおいてもマスターノードであることを承認して、ノード２〜ノードＮが継続してスレーブノードであり、ノード２〜ノードＮにおいて悪意のあるノードが生じても、クライアントからのメッセージを偽造できず、ノードの合意形成効率を確保する。

【0189】

方式２)：マスターノードは、合意形成回数がマスターノードの合意形成回数の閾値を超えたと統計した場合に、マスターノードは、スレーブノードが第１のコンセンサスモードに戻ることをトリガーし、スレーブノードは、合意形成回数の閾値がスレーブノードの合意形成回数の閾値を超えたと統計した場合に、スレーブノードは、第１のコンセンサスモードに戻ることを確認し、マスターノード及びスレーブノードは、第１のコンセンサスモードに切り替えるときに第２のコンセンサスモードにおけるノード状態を継承する(即ち、ノードがマスターノード又はスレーブノードである状態は変わらないままである)。

【0190】

分散システムが第２のコンセンサスモードにあるときに、スレーブノードは、第２のコンセンサスモードにおいてクライアントからのメッセージに関して他のノード(マスターノード及び他のスレーブノードを含む)と合意形成する回数を統計し、合意形成回数がスレーブノードの合意形成回数の閾値を超えていれば(マスターノードの合意形成回数の閾値以下であってもよく、例えば、Ｍ／２であることができる)、マスターノードが第１のコンセンサスモードにおいて継続してマスターノードであることに同意する旨の通知をマスターノードへ送信し、第２のコンセンサスモードにおけるスレーブノードは、第１のコンセンサスモードに切り替えるときに継続してスレーブノードであり、これにより、第１のコンセンサスモードに切り替える投票操作を完成し、継続して第１のコンセンサスモードにおいてクライアントからのメッセージに関して合意形成する。このように、第１のコンセンサスモードにおいて悪意のあるノードがマスターノードになることを回避することができ、合意形成効率を確保する。

【0191】

分散システムのノードが第１のコンセンサスモードに切り替わった後、第１のコンセンサスモードにおいて異常ノードを検出していなければ、継続して第１のコンセンサスモードを保持し、第１のコンセンサスモードに戻った後でもよく合意を達成していなければ(例えば、依然として悪意のあるノード、異常ノード又はエラーノードを検出していれば)、再び第２のコンセンサスモードに切り替える。

【0192】

ここでの所定数／割合は前の説明に基づいて理解されることができ、その説明を繰り返さない。

【0193】

例えば、分散システムのマスターノードは、カウンターに基づいて、第２のコンセンサスモードに切り替わることと同期して計時を開始でき、計時時間が計時時間閾値(例えば、１０分間)に達した後、分散システムのスレーブノードが同期して第１のコンセンサスモードに戻るようにトリガーし、第１のコンセンサスモードにおいて投票操作を実行することで、新しいマスターノード及びスレーブノードが決定される。第１のコンセンサスモードに切り替わった後でも異常ノードを検出していれば、再び第２のコンセンサスモードに切り替える(第１のコンセンサスモードに切り替える方式は前の説明に基づいて理解されることができる)。これにより、第２のコンセンサスモードを用いて合意形成することで、分散システムのフォールトトレランス性能を保証する前提において、分散システムの合意形成効率を最大限に向上させる。

【0194】

ここでの所定数／割合は前の説明に基づいて理解されることができ、その説明を繰り返さない。

【0195】

例えば、分散システムが第２のコンセンサスメカニズムにあり、ノード１をマスターノードとし、ノード２〜ノードＮをスレーブノードとすると、各ノードがクライアントからのメッセージに関して合意形成することをカウントし、ノード１にとって、ノード１とノード２〜ノードＮは、最近クライアントから送られたＭ個(マスターノードの合意形成回数の閾値)のメッセージのそれぞれに関して合意を達成していれば、各ノードでよく合意を達成したことが示され、ノード１は、第１のコンセンサスモードに切り替える旨の通知をノード２〜ノードＮへ放送し、ノード２〜ノードＮにとって、ノード２を例として、ノード２は、第２のコンセンサスモードにおいて合意形成した回数を統計し、Ｍ／２を超えていれば、ノード１へ切替確認を送信する(ノード１が第１のコンセンサスモードに切り替える時でもマスターノードであり、ノード２がスレーブノードであることを承認する)。ノード３〜ノードＮに関しての処理はノード２に類似し、その説明を繰り返さない。

【0196】

ノード１は、ノード２〜ノードＮのうちのそれぞれのノードから送信された切替確認を受信した場合に、第１のコンセンサスモードに切り替え、第１のコンセンサスモードにおいて、ノード１がマスターノードであり、ノード２〜ノードＮがスレーブノードである。ノード１がノード２〜ノードＮのうちのそれぞれのノードから送信された切替確認を受信していなければ、継続して第２のコンセンサスモードに留まり、Ｍ／２回の合意おきに、ノード１は、ノード２〜ノードＮのうちの全てのノードの切替確認を受信するまで、第１のコンセンサスモードに切り替える旨の通知を継続してノード２〜ノードＮへ送信する。

【0197】

以下、ブロックチェーンシステム(例えば、それぞれの個人又はエンティティに開放されるコンソーシアムチェーンシステム)が第１のコンセンサスモードにおいて改良型ＲＡＦＴ(Ｔ−ＲＡＦＴ)アルゴリズムを利用し、第２のコンセンサスモードにおいてＰＢＦＴアルゴリズムを利用して合意形成することを例として説明するが、第１のコンセンサスモードにおいてPaxosアルゴリズムを利用してもよく、第２のコンセンサスモードにおいてＢＦＴアルゴリズム、ＢＦＴ−ＲＡＦＴ等を利用してもよいことは理解されることができる。第１のコンセンサスモードでは、合意形成効率が高く、ノードの障害又はビザンチンノードを検出できる任意のアルゴリズム、例えばＴ−ＲＡＦＴアルゴリズムを利用でき、第２のコンセンサスモードでは、ビザンチンフォールトトレランスを実現できるアルゴリズムを利用できる。

【0198】

関連技術に提供されるＲＡＦＴアルゴリズムは、複数のノードデータの一致性問題のみを解決しているが、ビザンチンフォールトトレランスを解決していないものの、効率が比較的に高い。ＰＢＦＴアルゴリズムは、ビザンチンフォールトトレランスを解決できるが、しかし、ＰＢＦＴアルゴリズムでは、ノードにおいてメッセージ放送を行う必要があるため、実現効率が比較的に低い。

【0199】

分散ネットワークがコンソーシアムチェーン(それぞれの個人又はエンティティに開放されるブロックチェーン)に適用される使用場面において、一般的には、ブロックチェーンシステムはほとんどの場合、ノードの障害がなければ、ビザンチンノード問題もなく、ＲＡＦＴのアルゴリズムを利用することでノード間で合意を高効率に形成できる。

【0200】

関連技術に提供されるＲＡＦＴは、複数のノードの一致性問題を解決し、効率が比較に高いが、しかし、ノード間でのビザンチンフォールトトレランス問題を解決しておらず、一方、ＰＢＦＴアルゴリズムは、複数のノードの一致性を保証できるとともに、各ノード間でのビザンチンフォールトトレランスを解決している。このため、本発明の実施形態では、ノードにエラーが生じた場合に、或いはビザンチン問題が生じた場合に、ＰＢＦＴアルゴリズムを自動的に用いて各ノード間で合意形成でき、全てのノードがそれぞれ合意を達成し、即ち、ビザンチンノードがない場合に、再び合意形成効率の高いＲＡＦＴアルゴリズムに自動的に切り替えて、各ノード間で合意形成する。

【0201】

図８を参照すると、図８は、発明の実施形態に提供されるブロックチェーンシステムがＲＡＦＴアルゴリズムを利用して合意形成する１つの任意的なフロー模式図であり、クライアントがメッセージをマスターノード(leaderノード)へ送信した後、マスターノードは、受信されたメッセージを並び替え、並び替える順に従ってスレーブノード(followerノード)に配布し、他のfollowerは、leaderノードが並び替えた順に従ってメッセージをログに記憶し、leaderノードへＲＰＣ結果(result)を返信し、その後、leaderノードは、ログにおけるメッセージをローカルの磁気ディスクに記憶してから、各スレーブノードへコミット(Commit)を送信し、各スレーブノードは、ログにおけるメッセージをスレーブノードのローカル磁気ディスクに記憶すれば、メッセージの一致性を同期させることを完成し、効率が高いが、ビザンチンノード問題を解決できない。

【0202】

図９を参照すると、図９は、発明の実施形態に提供されるブロックチェーンシステムがＰＢＦＴアルゴリズムを利用して合意形成する１つの任意的なフロー模式図であり、１つのメッセージは、２回放送された後に正式に確認されることができ、放送に依存するため、合意形成のプロセスで送信されるメッセージ数は、ノード数の２乗となるため、合意形成効率が比較的に低いが、ノード間でのビザンチンフォールトトレランス問題を解決できる。

【0203】

ＲＡＦＴアルゴリズムは、一致性問題を解決でき、かつ効率が高いが、ビザンチンフォールトトレランス問題を解決できないため、ブロックチェーンシステムの多くの場面において採用されず、効率が相対的に低いがビザンチンフォールトトレランスを解決できるＰＢＦＴアルゴリズムしか採用できない。本発明の実施形態は、コンソーシアムチェーンにおける応用場面では、多くの場合、ネットワーク条件が良好で、かつビザンチンノードがなく、マルチノード間で合意形成できればよいという特徴を十分に活かし、ＲＡＦＴの高効率およびＰＢＦＴのフォールトトレランスの利点を結合して、効率が高いとともに、ビザンチンフォールトトレランス問題を解決できる自己適応型コンセンサスアルゴリズムを提供する。

【0204】

コンソーシアムチェーンに適用されるブロックチェーンシステムにおいて、合意形成に参加するノード数は限られるとともに、ほとんどの場合、各参加ノードはビザンチンノードがなく、データの一致性を保証すればよく、この場合、効率が高いＴ−ＲＡＦＴアルゴリズムを利用する。異常が発生し、例えば、ノード間でビザンチンフォールトトレランスニーズがあるか、或いはノードに障害が発生した場合に、これをタイムリーに検出できるとともに、ビザンチンフォールトトレランスをサポートできるＰＢＦＴアルゴリズムに自動的に切り替えることができ、ＰＢＦＴアルゴリズムにおいて全てのノードが合意した場合に、再び効率の高いＴ−ＲＡＦＴアルゴリズムに自動的に切り替え、このように、ほとんどの場合、即ち、ネットワークが良好で、ビザンチンノードがない場合に、コンソーシアムチェーンの高効率な合意形成要求を満たすことができる一方、異常ノードがある場合に、リアルタイムに修正し、フォールトトレランスを実現できる。

【0205】

コンセンサスアルゴリズムの自動的な切り替えを実現するために、図１０を参照すると、図１０は、本発明の実施形態に提供される自己適応型コンセンサスアルゴリズムを実現する運転状態図であり、ブロックチェーンシステムは、デフォルトに、Ｔ−ＲＡＦＴアルゴリズムで合意形成し、Ｔ−ＲＡＦＴアルゴリズムによってデータが一致しないノードが閾値よりも低い(全てのノード数、或いは、所定の割合のノードであり、Ｔ−ＲＡＦＴアルゴリズムのフォールトトレランス性能に基づいて設定される)と検出した場合に、以下のようなデータ(メッセージ)の一致性の確認状態に入る。各ノードのデータが一致すると確認していれば、Ｔ−ＲＡＦＴアルゴリズムに戻る。ノードのデータが一致していなければ、ＰＢＦＴアルゴリズムに変換してノード間での合意を実現する。ＰＢＦＴアルゴリズムの運転時に全てのノードのデータが一致すると検出していれば、Ｔ−ＲＡＦＴアルゴリズムに切り替える。

【0206】

Ｔ−ＲＡＦＴアルゴリズムはＲＡＦＴアルゴリズムを改良したものであり、ノードによるメッセージの改ざん、メッセージの再生、メッセージの偽造を防止できるとともに、悪意のあるノードをタイムリーに発見できる。図１１を参照すると、図１１は本発明の実施形態に提供されるＴ−ＲＡＦＴアルゴリズムによる合意形成の実現模式図であり、ＲＡＦＴアルゴリズムに比べ、主に以下の改良点がある。

【0207】

１．クライアント(Client)から送信されたメッセージに、メッセージのメッセージボディに対する電子署名が携帯されており、これにより、メッセージの伝送中に修正されたりすることを防止でき、そして、メッセージに一意のフィールドが携帯され、メッセージが横取りされた後再生されることを防止できる。

【0208】

２．各ノード間で伝送されるメッセージに送信側の電子署名が携帯され、メッセージの受信ノードはそれぞれ電子署名の正確性を検証し、これにより、新しいノードが偽造されて投票操作に参加するか、或いは、マスターノードになりすましてスレーブノードへ偽りのメッセージを送信することを防止できる。

【0209】

３．クライアントが要求をマスターノードへ送信した後、Ｔ−ＲＡＦＴコンセンサスモードにおけるマスターノードがメッセージをスレーブノードへ同期して送信するプロセスにおいて、全てのスレーブノードがマスターノードから送信されたメッセージを受信した後、元のＲＡＦＴのメッセージフローを完成する以外に、いずれも結果をクライアントへ返信し、返信された結果に、メッセージにおける一意のフィールド及びスレーブノードの電子署名が携帯されている。このように、クライアントは、全てのノードから返信された結果が一致するか否かを比較することで、各ノードのデータ(メッセージ)の一致性を判断できる。クライアントの受信した結果が一致しないか、或いは、所定の時間内には全てのノードの結果を受信していなければ、ビザンチンノードが存在するか、或いは障害ノードが存在すると判断し、データ一致性確認フローをトリガーする。

【0210】

データ一致性確認のプロセスは、コンセンサスアルゴリズムを切り替える中間段階に発生し、データ復元のプロセスは、実際には、多数決の合意形成のプロセスであり、合意形成のプロセスではメッセージ放送方式を利用し、具体的には、ノードは、デフォルトにＴ−ＲＡＦＴアルゴリズムを利用する。エラーになったノードがある場合に、或いは、ビザンチンノードがある場合に、クライアントは、各ノードから返信された結果を比較することで、データが一致しない状況を発見でき、アルゴリズム切替を行う必要があるか否かを判断する。

【0211】

例を挙げれば、ＰＢＦＴアルゴリズムのコンセンサスモードに切り替える必要があれば、クライアントは、ＰＢＦＴアルゴリズムに切り替える旨の通知を各ノードへ放送し、ノードがコンセンサスアルゴリズム切替通知を受信して準備(Prepare)段階にある場合に、データ要求確認メッセージを全ての他のノードに放送し、データ要求確認メッセージに、ノードのブロックチェーンにおける最近合意形成したブロックのハッシュ値及びノードの電子署名が携帯されている。

【0212】

データ要求確認メッセージを受信したノードは、ここで「受信ノード」と呼ばれ、ノードのブロックチェーンにおける最新の合意形成したブロックのハッシュ値とデータ要求確認メッセージに携帯されたハッシュ値とが一致するか否かを検査するとともに、ノードの電子署名の正確性を検証し、受信ノードは、全ての他のノードのデータ要求確認メッセージを受信し、これらのデータ要求確認メッセージの署名が正しく、かつ受信ノードの最新の合意形成したブロックのハッシュ値と一致していれば、クライアントへ、受信ノードの電子署名が携帯されているデータ一致性確認を返信する。

【0213】

クライアントが全てのノードのデータ一致性確認を受信していれば、各ノードの維持したブロックチェーンのデータが一致すると認めるとともに、アルゴリズム切替要求前のデータ一致性照合が失敗したのは、ネットワークの変動又は応答メッセージを破棄したことによるものであると認め、再びＴ−ＲＡＦＴアルゴリズムに切り替える。具体的なフローは下記のメッセージフローチャートを参照できる。

【0214】

一例として、図１２を参照すると、図１２は、本発明の実施形態に提供されるＰＢＦＴアルゴリズムへの切替準備段階においてＴ−ＲＡＦＴアルゴリズムに戻る１つの任意的なフロー模式図であり、図１２において、ノード１、２、３、４はいずれも他のノードからのデータ一致性確認の放送メッセージを受信しているとともに、各ノードの最新の合意形成したブロックのハッシュ値が一致すると確認し、各ノードはそれぞれデータ一致性確認をクライアントへ返信するとともに、それぞれＴ−ＲＡＦＴアルゴリズムの状態を返信し、クライアントが再びＴ−ＲＡＦＴに切り替える旨の通知はノードに到達していなくても、ノードはタイムアウト時間が到着した後、Ｔ−ＲＡＦＴアルゴリズムの投票フローに入る。

【0215】

タイムアウト時間内にクライアントが全てのノードのデータ一致性確認を受信していなければ、或いは、合意したノード(即ち、ブロックチェーンシステムにおける最新のブロックのハッシュ値が一致するもの)が他の全てのノードのデータ一致性確認の放送メッセージを受信していなければ、クライアントは、ＰＢＦＴアルゴリズムに切り替えるように全てのノードに通知する。

【0216】

また、いずれのノードが他の全てのノードのデータ一致性確認の放送メッセージを受信していなければ、ＰＢＦＴアルゴリズム状態に自動的に入ると共に、ＰＢＦＴアルゴリズムに切り替える旨の通知を放送する。

【0217】

ノードがｆ＋１個以上の新アルゴリズム放送メッセージを受信した後(ｆは、ＰＢＦＴアルゴリズムに基づいてブロックチェーンシステムにおいて許容されるエラーノードの最大値である)、新アルゴリズム(ＰＢＦＴ)中のマスターノードの投票を開始し、ビューの変更(view change)とも呼ばれ、完成した後、新しいＰＢＦＴアルゴリズムの合意形成段階に入る。

【0218】

図１３を参照すると、図１３は、本発明の実施形態に提供されるブロックチェーンシステムがＴ−ＲＡＦＴアルゴリズムによる合意形成からＰＢＦＴアルゴリズムによる合意形成に切り替える１つの任意的なフロー模式図であり、このメッセージフロー模式図において、仮にノード４は障害が発生したものであり、ノード１、２及び３は、クライアントからアルゴリズム切替通知を受信してＰＢＦＴアルゴリズムへの切替準備段階にあるとすると、それぞれデータ要求確認メッセージを放送し、メッセージに、自分の最新の合意形成したブロックのハッシュ値が付いており、ノード４は障害が発生したものであるため、ノード１、２、３はタイムアウト時間内にノード４の放送したデータ一致性確認(一致性応答)を受信できないので、データ一致性確認をクライアントへ送信することなく、ノード１、２、３及びクライアントはタイムアウトした後、それぞれ、ＰＢＦＴアルゴリズムに切り替える旨の通知を放送し、ノード１、２、３はいずれもアルゴリズム切替通知を受信し、アルゴリズム切替通知がｆ＋１よりも大きく、ｆ＋１個のアルゴリズム切替通知を真っ先に受信したノードは、まず最初にビューの変更フローを開始し、ビューの変更が完成した後、ＰＢＦＴアルゴリズムによる合意形成に入る。

【0219】

ＰＢＦＴによる合意形成において、マスターノードは、データが完全に一致することが連続してＭ回(設定可能)発生したと統計していれば、Ｔ−ＲＡＦＴの競合ノードに変換し、Ｔ−ＲＡＦＴの投票プロセスをトリガーし、他のノードが投票要求を受信した後、連続した合意形成回数がＭ／２回を超えるか、或いは、一定の設定値Ｔを超えると統計していれば、競合ノードがマスターノードに変換することに同意し、全てのスレーブノードはそれぞれ競合ノードがマスターノードに変換することに同意した場合にのみ、Ｔ−ＲＡＦＴアルゴリズムのコンセンサスモードに入り、各ノードの連続した合意形成回数は０へとクリアされる。競合ノードがマスターノードに変換することに同意しないスレーブノードが１つでもあれば、競合ノードはすぐに元の状態に戻り、即ち、ＰＢＦＴアルゴリズムのマスターノードに変換し、継続してＰＢＦＴアルゴリズムを実行し、各ノードの合意形成統計回数は継続して累積し、Ｍ＋Ｔになってから再びＴ−ＲＡＦＴ投票をトリガーし、成功しなければ、Ｍ＋２Ｔ時刻で次回のトリガーを行い、マスターノードの投票が成功するまでこのように繰り返し、Ｍ＋ｘ＊Ｔ時刻でトリガーし、ここで、ｘは回数である。

【0220】

図１４を参照すると、図１４は、本発明の実施形態に提供されるブロックチェーンシステムがＰＢＦＴアルゴリズムのコンセンサスモードからＴ−ＲＡＦＴアルゴリズムのコンセンサスモードに切り替える１つの任意的なフロー模式図であり、ＰＢＦＴアルゴリズムのプロセスにおいて、マスターノード、即ちノード１は、データが連続して一致する(合意形成する)回数がＭ回を超えると統計した場合に、Ｔ−ＲＡＦＴの競合ノード状態に変換し、その後、Ｔ−ＲＡＦＴアルゴリズムの投票を開始し、ノード２、３及び４は、投票要求(request vote)メッセージを受信した後、連続してデータが一致する回数がＭ／２(又は、一定の値Ｔ)を超えると統計したか否かを判断し、ＹＥＳであれば、競合ノードがマスターノードに変換することに同意する旨の切替確認を返信する。

【0221】

競合ノードは、ノード２、３、４の切替確認を受信し、マスターノードに変換し、Ｔ−ＲＡＦＴアルゴリズムの合意形成段階を開始する。Ｔ−ＲＡＦＴ投票プロセスにおいて、元のＰＢＦＴコンセンサスモードにおけるマスターノード(ノード１)がクライアントのメッセージを受信した後、これ以上シークエンシングメッセージ、例えば、ＰＢＦＴアルゴリズムにおける事前準備(PRE-PREPARE)メッセージを送信しなくなり、投票が完了したら、Ｔ−ＲＡＦＴにおいてメッセージをAppend Entries ＲＰＣに付加させてスレーブノードへ送信する。

【0222】

さらに、実際の適用時の使用場面を結合して説明し、図１５を参照すると、図１５は、本発明の実施形態に提供される分散システムがコンソーシアムチェーンシステムに適用される１つの任意的なシーン模式図であり、コンソーシアムチェーンシステムはそれぞれの個人又はエンティティに開放されるものであり、複数のノードを含み、各ノードは第３者決済機構、及び銀行業務システム(クライアントとして)のためにアクセスを提供し、第３者決済機構、及び銀行業務システムのコミットした取引履歴を受け取り、ノードは、コミットした取引履歴に関して合意形成した後、この取引履歴をブロックチェーンの最新のブロックに記憶し、これにより、第３者決済機構及び契約を結んだ銀行はそれぞれの業務取引明細書に基づいて照合する。

【0223】

ノードは、デフォルトに、Ｔ−ＲＡＦＴコンセンサスモードを用いて取引履歴に対する合意を形成し、異常ノードが発生した場合にＰＢＦＴコンセンサスモードに切り替えて取引履歴に関しての合意を形成する。

【0224】

ユーザの第３者決済端末に、ユーザの銀行におけるクレジットカード口座がボンディングされ、ユーザがベンダーとオフライン又はオンラインで取引する際に、第３者決済端末は、クレジットカードのアカウントの事前承認を予め得ることで、ユーザのクレジットカード口座からベンダーの口座を引き落としすることができ、取引履歴を形成する。

【0225】

この取引の場合、第３者決済機構の業務システムは、分散システムにてアクセスするマスターノードへ取引履歴(例えば、受取人、支払人及び支払額を含み、第３者決済クライアントの電子署名が携帯されている)をコミットする。マスターノードは、受信された取引履歴の電子署名の検証に成功した後、取引履歴を同期して他のスレーブノードへ送信し(マスターノードの電子署名が携帯されている)、スレーブノードは、取引履歴の電子署名の検証に成功した後、第３者決済機構の業務システムへ結果を返信する(スレーブノードの電子署名、一意のフィールドが携帯され、マスターノードが新しいマスターノードとして投票された場合に、取引履歴の配列番号がさらに携帯されている)一方、同期が完了したことをマスターノードに通知する。マスターノードは、各スレーブノードの同期が完了したと確認した後、取引履歴をブロックチェーンの最新のブロックに記憶して各スレーブノードに通知し、スレーブノードが同様な操作を実行し、取引履歴の永続的な記憶を完成する。

【0226】

上述した取引履歴に関する合意形成のプロセスにおいて、クライアントは、スレーブノードから返信された結果に基づいて、マスターノードが悪意のあるノードであるか、或いは、スレーブノードに障害が発生したと決定していれば、コンソーシアムチェーンシステムがＰＢＦＴコンセンサスモードに切り替えて取引履歴に関して合意形成するようにトリガーし、取引履歴が各ノードのブロックチェーンに順調に記憶されることを保証する。コンソーシアムチェーンシステムが第３者決済機構の業務システムが後でコミットした取引履歴の合意状況に応じて、よく合意を達成していれば(マスターノードと他のノードが連続してＭ回合意する)、Ｔ−ＲＡＦＴコンセンサスモードに戻って合意形成効率を向上させることができる。

【0227】

上述のように、本発明の実施形態は、以下の有益な効果を有する。

【0228】

１)クライアントとノード間、ノード同士間では電子署名の方式により通信の信頼性を保証し、メッセージの偽造を回避し、分散システム内部の通信の信頼性を保証する。

【0229】

２)スレーブノードは、マスターノードから送信されたメッセージを受信した場合に、結果を直接クライアントへ返信し、結果に、例えば一意のフィールド、メッセージ配列番号及び電子署名等の必要な情報が携帯され、このように、クライアントは、直接スレーブノードから返信された結果に基づいてスレーブノードの合意状況を判定でき、異常ノードを容易に検出できる。

【0230】

３)異常ノードを検出した場合に、デフォルトに利用される合意形成効率の高い第１のコンセンサスモードからフォールトトレランス性能のより優れた第２のコンセンサスモードに切り替えることができ、分散システムは異常が発生した時でも順調に合意形成できることを確保する。

【0231】

４)第２のコンセンサスモードにおいてよく合意を達成していれば(例えば、合意形成回数に基づいて判断する)、再び第１のコンセンサスモードに切り替え、このような適応型コンセンサスモードの切替は、合意形成効率とフォールトトレランス性能をうまく両立させている。分散システムの運転するネットワーク状態が良好であるほとんどの時間内に、合意形成効率が高いという技術効果を実現し、ノードに障害が発生し、或いはビザンチンノードがある場合に、分散システムの業務機能を正常に処理できることを保証する。

【0232】

上述した方法実施形態を実現するステップの全部又は一部は、プログラムが関連するハードウェアを命令して完成させることができ、上述したプログラムは、コンピュータ読み取り可能な記憶媒体に記憶されることができ、このプログラムは、実行される際に、上述した方法実施形態を含むステップを実行する、と当業者が理解することができる。上述した記憶媒体は、モバイル記憶通信状態処理装置、ランダムアクセスメモリ(ＲＡＭ、Random Access Memory)、リードオンリーメモリ(ＲＯＭ、Read-Only Memory)、磁気ディスク又は光ディスク等、様々なプログラムのコードを記憶可能な媒体を含む。

【0233】

或いは、本発明の上記集積したユニットは、ソフトウェア機能モジュールの形で実現されながら独立した製品として販売または使用される場合、コンピュータ読み取り可能な記憶媒体に記憶されることができる。このように理解すれば、本発明の実施形態の技術的構成は、本質的には、従来技術に貢献する部分、或いは、該技術的構成の全部又は一部をソフトウェア製品の形で表現でき、このコンピュータソフトウェア製品は、コンピュータデバイス（パソコン、サーバまたはネットワークデバイス等であってもよい）に本開示の各実施形態に記載の方法の全部又は一部を実行させるための若干の命令を含む記憶媒体に記憶される。上記記憶媒体は、モバイル記憶通信状態処理装置、ＲＡＭ、ＲＯＭ、磁気ディスク又は光ディスク等、様々なプログラムのコードを記憶可能な媒体を含む。

【0234】

以上は、あくまでも本発明の具体的な実施形態であり、本発明の保護範囲はこれに限定されず、当業者が本発明に開示された技術範囲内において容易に想到し得る変更又は置き換えは、いずれも本発明の保護範囲内に含まれるべきである。それゆえ、特許請求の範囲の内容に基づいて本発明の保護範囲が定められるべきである。

【符号の説明】

【0235】

２００ ノード
２１０ プロセッサ
２２０ ネットワークインターフェース
２３０ 記憶媒体
２４０ 入出力インターフェース
２５０ ミドルウェア
２６０ オペレーティングシステム
２７０ コンセンサスメカニズム
２７０１ 投票ユニット
２７０２ マスターノードユニット
２７０３ スレーブノードユニット
２７０４ 切替ユニット
２８０ 電子マネーウォレット
２９０ スマートコントラクト
３００ クライアント
３１０ プロセッサ
３２０ ネットワークインターフェース
３３０ 記憶媒体
３４０ 入出力インターフェース
３５０ ミドルウェア
３６０ オペレーティングシステム
３７０ コンセンサス
３７０１ 通信ユニット
３７０２ 検出ユニット
３７０３ 切替ユニット
３８０ 管理ノード
３９０ 配置されるスマートコントラクト

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】