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

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

Info

Publication number
JP2020512708A
JP2020512708A JP2019531777A JP2019531777A JP2020512708A JP 2020512708 A JP2020512708 A JP 2020512708A JP 2019531777 A JP2019531777 A JP 2019531777A JP 2019531777 A JP2019531777 A JP 2019531777A JP 2020512708 A JP2020512708 A JP 2020512708A
Authority
JP
Japan
Prior art keywords
node
message
distributed system
client
slave
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019531777A
Other languages
English (en)
Other versions
JP2020512708A5 (ja
JP6883106B2 (ja
Inventor
▲鋭▼ 郭
▲鋭▼ 郭
茂材 李
茂材 李
▲チ▼ ▲趙▼
▲チ▼ ▲趙▼
建俊 ▲張▼
建俊 ▲張▼
▲海▼涛 ▲屠▼
▲海▼涛 ▲屠▼
宗友 王
宗友 王
▲軍▼ 梁
▲軍▼ 梁
大▲衛▼ 朱
大▲衛▼ 朱
立生 ▲陳▼
立生 ▲陳▼
斌▲華▼ ▲劉▼
斌▲華▼ ▲劉▼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Publication of JP2020512708A publication Critical patent/JP2020512708A/ja
Publication of JP2020512708A5 publication Critical patent/JP2020512708A5/ja
Application granted granted Critical
Publication of JP6883106B2 publication Critical patent/JP6883106B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023Failover techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0847Transmission error
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81Threshold
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/83Indexing scheme relating to error detection, to error correction, and to monitoring the solution involving signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Environmental & Geological Engineering (AREA)
  • Power Engineering (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本発明は、分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体を開示する。分散システムは、クライアントと複数のノードとを備え、マスターノードは、クライアントのメッセージを受信し、メッセージの電子署名の検証に成功した後、前記メッセージをスレーブノードに送信し、所定数のスレーブノードの受信確認通知を受信し、電子署名の検証に成功した後、前記メッセージを永続的に記憶し、スレーブノードへメッセージ記憶通知を送信し、スレーブノードは、マスターノードから送信されたメッセージを受信したときにクライアントへ結果を返信し、受信されたメッセージの電子署名の検証に成功した後、マスターノードへ受信確認通知を送信し、受信されたメッセージ記憶通知の電子署名の検証に成功した後、受信されたメッセージを永続的に記憶し、クライアントは、スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、異常ノードを決定する。

Description

関連する出願の参照
本願は、出願番号が201710203499.Xで、出願日が2017年3月30日である中国特許出願に基づくものであり、該中国特許出願の優先権を主張し、その内容を全て参照により本願に組み込むものとする。
本発明は、通信技術に関し、特に、分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体に関する。
分散システムは、現在一般的に利用される計算システムであり、ブロックチェーン、分散型サービスフレーム(例えば、ZooKeeper)など、様々な分野に適用されている。
分散システムの動作プロセスにおいて、ノードは、クライアントからの処理すべきメッセージについて合意形成(Consensus)する必要があり、即ち、分散システムの全てのノード又は多くのノードは受信されたメッセージを確認してから、メッセージを同期して記憶/処理する。
例えば、分散システムがプライベートブロックチェーン又はコンソーシアムブロックチェーンに適用される場合に、各ノードは、クライアントのコミットした取引履歴に関してコンセンサスアルゴリズムに基づいて合意形成し(即ち、取引履歴の信頼性を確認し)、取引履歴を各ノードが維持するブロックチェーンに記憶して、各ノードに記憶される取引履歴の一致性を保証する。
関連技術で実現される分散システムの利用するコンセンサスアルゴリズムは、合意形成効率に重点を置くか、或いは、合意形成のプロセスにおいて一定のフォールトトレランス性能を保証し、フォールトトレランス性能とは、障害ノード又は悪意のあるノードが存在する場合でも、多くのノードが依然として合意形成できることを保証することを意味する。
関連技術に提供される合意形成効率を保証するためのコンセンサスアルゴリズムは、障害ノード及び悪意のあるノードを検出できないので、合意形成の信頼性を保証できない。
本発明の実施態様は、分散システムにおけるノードがメッセージに関して信頼できる合意形成を実現できる分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体を提供する。
本発明の実施態様の技術的構成は、以下のように実現される。
第1の態様によれば、本発明の実施態様は、分散システムであって、
クライアントと複数のノードとを備え、
前記ノードは、第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成され、
前記ノードは、マスターノードの状態にある場合に、前記クライアントから送信されたメッセージの電子署名を検証し、前記メッセージを前記スレーブノードへ送信するように構成され、
前記ノードは、マスターノードの状態にある場合に、所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成され、
前記ノードは、さらに、スレーブノードの状態にある場合に、前記マスターノードから送信された前記メッセージを受信したときに前記クライアントへ結果を返信し、前記マスターノードから受信したメッセージの電子署名を検証して、前記マスターノードから受信したメッセージを永続的に記憶するように構成され、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される、分散システムを提供する。
第2の態様によれば、本発明の実施態様は、分散システムにおけるノードに適用可能なメッセージ処理方法であって、
第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、分散システムにおけるノード投票操作を実行し、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されることと、
前記ノードがマスターノードの状態にある場合に、前記ノードは、
前記クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信する操作と、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信する操作とを実行することと、を含み、
前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、メッセージ処理方法を提供する。
第3の態様によれば、本発明の実施態様は、分散システムにおけるクライアントに適用可能なメッセージ処理方法であって、
クライアント分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信することと、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは前記マスターノードの電子署名を携帯されて、前記分散システムにおけるスレーブノードへ送信することと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果を受信することと、
前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することと、を含む、メッセージ処理方法を提供する。
第4の態様によれば、本発明の実施態様は、分散システムに適用可能なノードであって、
第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される投票ユニットと、
前記ノードがマスターノードの状態にある場合に、前記クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信し、そして、
所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成されるマスターノードユニットと、を備え、
前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、ノードを提供する。
第5の態様によれば、本発明の実施態様は、分散システムに適用可能なノードであって、1つ又は複数のプロセッサと、メモリと、1つ以上のプログラムとを備え、前記1つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれが一群の命令に対応する1つ以上のユニットを含むことができ、前記1つ又は複数のプロセッサは、命令を実行する際に、本発明の実施態様に提供されるノードに適用されるメッセージ処理方法を実現するように構成される、ノードを提供する。
第6の態様によれば、本発明の実施態様は、分散システムに適用可能なクライアントであって、
分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信し、
前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を携帯されて、前記分散システムにおけるスレーブノードへ送信し、
前記スレーブノードが前記メッセージを受信したときに返信した結果を受信するように構成される前記通信ユニットと、
前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される検出ユニットと、を備える、クライアントを提供する。
第7の態様によれば、本発明の実施態様は、分散システムに適用可能なクライアントであって、1つ又は複数のプロセッサと、メモリと、1つ以上のプログラムとを備え、前記1つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれが一群の命令に対応する1つ以上のユニットを含むことができ、前記1つ又は複数のプロセッサは、命令を実行する際に、本発明の実施態様に提供されるクライアントに適用されるメッセージ処理方法を実現するように構成される、クライアントを提供する。
第8の態様によれば、本発明の実施態様は、プロセッサに、実行可能なプログラムを実行する際に、本発明の実施態様に提供されるノードに適用されるメッセージ処理方法を実現させるための前記実行可能な命令が記憶されている記憶媒体を提供する。
第9態様によれば、本発明の実施態様は、プロセッサに、実行可能なプログラムを実行する際に、本発明の実施態様に提供されるクライアントに適用されるメッセージ処理方法を実現させるための前記実行可能な命令が記憶されている記憶媒体を提供する。
本発明の実施態様は、以下のような有益な効果を有する。
1)電子署名の方式を用いることで分散システムにおける通信の信頼性を保証し、任意の通信を行う双方はそれぞれ電子署名の方式を利用し、即ち、メッセージを送信する際にメッセージの電子署名を携帯させ、電子署名を検証することでメッセージの信頼性を保証する。
2)スレーブノードは、マスターノードから送信されたメッセージを受信するとき、結果を直接クライアントへ返信し、結果に、例えば、一意のフィールド、メッセージの配列番号及び電子署名等の必要な情報が携帯され、これにより、クライアントは、直接スレーブノードから返信された結果に基づいてスレーブノードの合意達成状況を判定でき、異常ノードを高効率に検出する。
本発明の実施形態に提供される分散システム100がブロックチェーンシステムに適用される1つの任意的な構造模式図である。 本発明の実施形態に提供されるブロック構造の1つの任意的な模式図である。 本発明の実施形態に提供されるノード200の1つの任意的なソフトウェア・ハードウェア構造模式図である。 本発明の実施形態に提供されるクライアント300の1つの任意的なソフトウェア・ハードウェア構造模式図である。 本発明の実施形態に提供される第1のコンセンサスモードにおいて各ノードが投票操作を実行することでマスターノード及びスレーブノードを決定する1つの任意的な模式図である。 本発明の実施形態に提供される分散システムのノードが第1のコンセンサスモードにおいて合意形成し、障害ノード及び悪意のあるノードを検出する1つの任意的なフロー模式図である。 本発明の実施形態に提供される分散システムが第1のコンセンサスモードと第2のモード間を切り替える1つの任意的なフロー模式図である。 本発明の実施形態に提供される分散システムが第1のコンセンサスモードと第2のモード間を切り替える1つの任意的なフロー模式図である。 発明の実施形態に提供されるブロックチェーンシステムがRAFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図である。 発明の実施形態に提供されるブロックチェーンシステムがPBFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図である。 本発明の実施形態に提供される自己適応型コンセンサスアルゴリズムを実現する運転状態図である。 本発明の実施形態に提供されるT−RAFTアルゴリズムによる合意形成の実現模式図である。 本発明の実施形態に提供されるPBFTアルゴリズムへの切替準備段階においてT−RAFTアルゴリズムに戻る1つの任意的なフロー模式図である。 本発明の実施形態に提供されるブロックチェーンシステムがT−RAFTアルゴリズムによる合意形成からPBFTアルゴリズムによる合意形成に切り替える1つの任意的なフロー模式図である。 本発明の実施形態に提供されるブロックチェーンシステムがPBFTアルゴリズムのコンセンサスモードからT−RAFTアルゴリズムのコンセンサスモードに切り替える1つの任意的なフロー模式図である。 本発明の実施形態に提供される分散システムがコンソーシアムチェーンシステムに適用される1つの任意的なシーン模式図である。
以下、図面及び実施形態を結合して本発明をさらに詳しく説明する。ここで提供される実施形態はあくまでも本発明を解釈するためのものであり、本発明を限定することを意図していないことは、理解されるべきである。また、衝突しない限り、本発明の実施形態に記載された技術的構成を任意に組み合わせて実施されることができる。
1)分散システム:複数のノードとクライアントとがネットワークを介して通信し接続されて形成されるシステムであり、ネットワーク通信に使用されるメッセージの内容は実際の業務シーンによって異なり、例えば、メッセージは、取引履歴、ノードのステートマシンが実行するための命令等であることができる。
2)コンセンサス:分散システムにおいて、ノードは他のノード(即ち、分散システムにおけるメッセージを送信したノードを除いた任意のノード)から送信されたメッセージの正確性を検証し、検証が成功していれば、メッセージの送信ノードへ確認を送信し、このメッセージを永続的に記憶して、後続の問い合わせをサポートするために用いる。
例えば、分散システムがブロックチェーンシステムとして実施される場合に、ノードは、他のノードのコミットした新しいブロック(新たに発生した取引履歴を含む)の有効性を検証し、検証が成功していれば、新しいブロックを送信したノードへ確認を送信し、この新しいブロックを、対応するノードに記憶されたブロックチェーンの末尾に追加して、ブロックチェーンにおける取引履歴の合意形成を完成する。
3)コンセンサスモード:コンセンサスアルゴリズムとも呼ばれ、分散システムのノードが合意形成することを保証するためのアルゴリズムであり、コンセンサスモードは、以下のタイプを含むことができる。
第1のコンセンサスモード:高い合意形成効率を実現できるとともに、ノードの障害又はビザンチン問題(一方が他方へメッセージを送信したが、他方が受信していないか、或いは、誤った情報を受信している場合)を検出できるが、しかし、ビザンチン問題を解決できないコンセンサスモードであり、一例として、第1のコンセンサスモードを実現するアルゴリズムは、Paxosアルゴリズム及び再帰のフォールトトレランスアルゴリズム(RAFT、Recursive Algorithm for Fault Tolerance)を含む。
第2のコンセンサスモード:ビザンチン問題を解決するためのコンセンサスモードであり、第2のコンセンサスモードを実現するアルゴリズムは、ビザンチンフォールトトレランス(BFT、Byzantine Fault Tolerance)アルゴリズム、実用的ビザンチンフォールトトレランス(PBFT、Practical Byzantine Fault Tolerance)アルゴリズム、再帰のフォールトトレランスアルゴリズム−ビザンチンフォールトトレランス(BFT−RAFT、Byzantine Fault Tolerance Recursive Algorithm for Fault Tolerance)、ビザンチンフォールトトレランス(BFT−Paxos)アルゴリズム等を含む。
4)コンセンサスモードの切替:コンセンサスモードの適応とも呼ばれ、分散ネットワークに使用されるコンセンサスアルゴリズムは、ネットワーク環境が良好である場合に、合意形成効率が高くて異常ノード(例えば、ビザンチン問題のあるノード)を検出できるアルゴリズムを自動的に利用して、第1のコンセンサスモードを実現するが、悪意のあるノード又はノードが誤っていることが判明した場合に、ビザンチンフォールトトレランスを解決できるアルゴリズムに自動的に切り替えて第2のコンセンサスモードを実現する。
本発明の実施形態を実現する分散システムは、クライアント、複数のノード(ネットワークにアクセスする任意の形態の計算機器、例えば、サーバ、ユーザ端末)がネットワークを介して通信する形で接続されてなり、以下、クライアント及びノードの機能について説明する。
ノードは、第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される。
ノードは、マスターノードの状態にある場合に、クライアントから送信されたメッセージの電子署名を検証して、メッセージをスレーブノードへ送信するように構成される。
ノードは、マスターノードの状態にある場合に、所定数を超えたスレーブノードの受信確認通知を受信し、受信確認通知の電子署名を検証した後にメッセージを永続的に記憶して、スレーブノードへメッセージ記憶通知を送信するように構成される。
ノードは、さらに、スレーブノードの状態にある場合に、マスターノードから送信されたメッセージを受信したときにクライアントへ結果を返信し、マスターノードから受信したメッセージの電子署名を検証して、マスターノードへ受信確認通知を送信するように構成される。
ノードは、スレーブノードの状態にある場合に、マスターノードから受信したメッセージ記憶通知の電子署名を検証して、マスターノードから受信したメッセージを永続的に記憶するように構成される。
クライアントは、スレーブノードがメッセージを受信したときに返信した結果に基づいて、分散システムにおける異常ノードを決定するように構成される。
一実施形態において、クライアントは、さらに、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定し、結果を返信していないスレーブノードを障害ノードとして決定するように構成される。
一実施形態において、クライアントは、さらに、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、マスターノードが悪意のあるノードであると判定するように構成される。
一実施形態において、クライアントは、さらに、マスターノードが悪意のあるノードであると決定し、或いは、スレーブノードに障害ノードが存在すると決定した場合に、分散システムにおけるノードが第2のコンセンサスモードに切り替えるようにトリガーする。
一実施形態において、ノードは、さらに、第2のコンセンサスモードに切り替える準備段階にあるときに、ノードに永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、対応するノードの電子署名が携帯されている一致性確認をクライアントへ送信するように構成される。
クライアントは、さらに、所定の時間内に全てのノードの一致性確認を受信した場合に、分散システムにおけるノードが第1のコンセンサスモードに戻るように通知し、所定の時間内には全てのノードの一致性確認を受信していない場合に、分散システムにおけるノードが継続して第2のコンセンサスモードに切り替えるように通知する。
一実施形態において、ノードは、さらに、第2のコンセンサスモードに切り替える準備段階にあるときに、ノードに永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、対応するノードの電子署名が携帯されているデータ確認を、メッセージの送信ノードへ送信するように構成される。
クライアントは、さらに、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、分散システムにおけるノードが継続して第2のコンセンサスモードに切り替えるようにトリガーする。
一実施形態において、ノードは、さらに、マスターノードの状態にあるとともに、第2のコンセンサスモードにおいて統計した回数であって、受信したメッセージに関してスレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、スレーブノードとともに第1のコンセンサスモードに切り替るように構成される。
一実施形態において、ノードは、さらに、マスターノードの状態にあるとともに、統計した回数がマスターノードの合意形成回数の閾値を超えた場合に、第1のコンセンサスモードに切り替える旨の通知をスレーブノードへ送信し、全てのスレーブノードから送信された切替確認を受信した場合に、スレーブノードと同期して第1のコンセンサスモードに切り替えるように構成される。
一実施形態において、ノードは、さらに、スレーブノードの状態にあり、第1のコンセンサスモードに切り替える旨の通知を受信し、かつ、受信したメッセージに関して合意形成した回数がスレーブノードの合意形成回数の閾値を超えると統計した場合に、マスターノードへ切替確認を送信するように構成される。
一実施形態において、ノードは、さらに、マスターノードの心拍情報を受信していない場合に、或いは、マスターノードが悪意のあるノードである場合に、投票操作を再実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される。
一実施形態において、ノードは、さらに、新しいコンセンサス周期が到来し、かついずれものノードから送信された心拍情報も受信していない場合に、分散システムにおけるノードへ投票要求を送信し、所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換して心拍情報を分散システムにおけるノードへ定期的に送信するように構成される。
投票確認は、分散システムにおけるノードが送信され、かつ送信される前には投票要求に携帯された電子署名は検証される。
一実施形態において、ノードは、さらに、新しいコンセンサス周期が到来し、かつ分散システムにおけるノードから送信された心拍情報を受信した場合に、スレーブノードの状態に変換するように構成される。
以下、分散システムがブロックチェーンシステムとして実施されることを例として説明し、図1を参照すると、図1は、本発明の実施形態に提供される分散システム100がブロックチェーンシステムとして実施される1つの任意的な構造模式図であり、複数のノード200(ネットワークにアクセスする任意の形態の計算機器であり、例えば、サーバ、ユーザ端末)からなり、クライアント300をさらに備え、ノード200間でピアツーピア(P2P、Peer To Peer)ネットワークが形成され、P2Pプロトコルは、伝送制御プロトコル(TCP、Transmission Control Protocol)にて実行されるアプリケーション層プロトコルである。
図1に示されるブロックチェーンシステムにおけるノード200の機能を参照し、かかる機能は、以下を含む。
1)ルーター:ノードが有する基本的な機能であり、ノード間の通信をサポートする。
ノード200は、ルーター機能を有するほか、以下の機能をさらに有してもよい。
2)アプリケーション:ブロックチェーンに配置され、実際の業務需要に応じて特定の業務を実現し、機能の実現に関するデータを記録して記録データを形成し、記録データには、ジョブデータの由来を表す電子署名が携帯されており、記録データをブロックチェーンシステムにおける他のノード(即ち、ブロックチェーンシステムにおける記録データを受信した任意のノード)へ送信し、これにより、他のノードが記録データの由来及び完全性の検証に成功したときに、記録データをテンポラリブロックに追加する。
例えば、アプリケーションで実現される業務は、以下を含む。
2.1)ウォレット:電子マネーでの取引を行う機能を提供し、取引を開始することを含み、即ち、現在行われている取引の取引履歴をブロックチェーンシステムにおける他のノードへ送信し、他のノードによる検証が成功した後、取引が有効であることを承認する応答として、取引が成立した記録データをブロックチェーンのテンポラリブロックに保存する。もちろん、ウォレットは、電子マネーアドレスにおける残りの電子マネーを問い合わせることをもサポートする。
2.2)共有元帳:会計データの記憶、問い合わせおよび修正等の操作の機能を提供し、会計データに対する操作の記録データをブロックチェーンシステムにおける他のノードへ送信し、他のノードによって有効であると検証された後、会計データが有効であることを承認する応答として、記録データをテンポラリブロックに保存する。さらに、操作を発したノードへ確認を送信してもよい。
2.3)スマートコントラクト:コンピュータ化されたプロトコルであり、ある契約の条項を実行でき、共有元帳に配置された、一定の条件を満たすときに実行されるコードによって実現され、実際の業務需要に応じて、コードは取引を自動的に完成し、例えば、バイヤが購入した商品の物流状態を問い合わせ、バイヤが受け取りサインをした後、バイヤの電子マネーをベンダーのアドレスに移動させる。もちろん、スマートコントラクトは、取引を実行するための契約に限らず、受信した情報の処理を実行する契約であってもよい。
3)ブロックチェーン:生成順に相互に繋がる一連のブロック(Block)を含み、新しいブロックがブロックチェーンに追加されると、削除されることはなく、ブロックに、ブロックチェーンシステムにおけるノードのコミットした記録データは記録されている。
一例として、図2を参照すると、図2は、本発明の実施形態に提供されるブロック構造(Block Structure)の1つの任意的な模式図であり、各ブロックには、本ブロックに記憶された取引履歴のハッシュ値(本ブロックのハッシュ値)、および前のブロックのハッシュ値が含まれ、各ブロックはハッシュ値によって接続されてブロックチェーンを形成する。また、ブロックには、ブロック生成時のタイムスタンプ等の情報が含まれてもよい。
本発明の実施形態を実現する分散システムの構成は、柔軟に変更できるという特徴を有し、例を挙げれば、分散システムにおいて、例えばサーバ、端末など、任意の機器は分散システムに追加されてノードとなることができ、ハードウェア面において、一例として、図3Aを参照すると、図3Aは、本発明の実施形態に提供されるノード200の1つの任意的なソフトウェア・ハードウェア構造模式図であり、ノード200は、ハードウェア層、駆動層、操作システム層及びアプリケーション層を含む。図3Aに示されるノード200の構造は一例に過ぎず、ノード200の構造を限定していないことは当業者に理解されるべきであり、例えば、ノード200は、実施のニーズに応じて図3Aよりも多い構成要素を設けるか、或いは、一部の構成要素を省略してもよい。
ノード200のハードウェア層はプロセッサ210、入出力インターフェース240、記憶媒体230およびネットワークインターフェース220を含み、その構成要素はシステムバスを介して接続されて通信できる。
プロセッサ210は、中央処理装置(CPU)、マイクロプロセッサ(MCU、Microcontroller Unit)、特定用途向け集積回路(ASIC、Application Specific Integrated Circuit)又はロジックプログラマブルゲートアレイ(FPGA、Field−Programmable Gate Array)を用いて実現されることができる。
入出力インターフェース240は、例えば表示画面、タッチパネル、スピーカ等の入出力デバイスを用いて実現されることができる。
記憶媒体230は、フラッシュメモリ、ハードディスク、光ディスク等の不揮発性記憶媒体を用いて実現されることができれば、ダブルデータレート(DDR、Double Data Rate)ダイナキャッシュ等の揮発性記憶媒体を用いて実現されることもでき、メッセージ処理方法を実行するための実行可能な命令を記憶している。
ネットワークインターフェース220は、プロセッサ210のために外部データへのアクセス能力、例えば、遠隔地に設けられた記憶媒体230へのアクセス能力を提供し、一例として、ネットワークインターフェース220は、例えば、符号分割多元接続(CDMA、Code Division Multiple Access)、広帯域符号分割多元接続(WCDMA(登録商標)、Wideband Code Division Multiple Access)等の通信方式及その進化方式に基づく通信を実現できる。
駆動層は、操作システム260がハードウェア層を認識し、ハードウェア層の各構成要素と通信するためのミドルウェア250を含み、例えば、ハードウェア層の各構成要素に対する駆動プログラムの集まりであることができる。
操作システム260は、ユーザに向けたグラフィカルインタフェースを提供し、ブロックチェーンに基づく様々なアプリケーション処理の様々な中間結果と最終結果を表示するように構成される。
アプリケーション層は、ノード間での合意形成を実現するように構成されるコンセンサスメカニズム270(第1のコンセンサスモードと第2のコンセンサスモード間を適応的に切り替えるように構成される)、および、ノードが分散システムに基づいて実現する機能、例えば、電子マネーウォレット280、スマートコントラクト290等を含み、第1のコンセンサスモードと第2のコンセンサスモードとを含む。
アプリケーション層に関して例を挙げれば、図3Aを参照すると、図3Aに提供されるノード200のアプリケーション層のコンセンサスメカニズム270は、以下を備える。
投票ユニット2701:第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、ノード200分散システムにおける他のノードが投票操作を実行することで、マスターノードの状態又はスレーブノードの状態にされるように構成される。
マスターノードユニット2702:ノード200がマスターノードの状態にある場合に、クライアントのメッセージを受信し、メッセージの電子署名を検証した後にメッセージをスレーブノードへ送信し、そして、所定数を超えたスレーブノードの受信確認通知を受信したとき、確認受信メッセージの電子署名を検証した後にメッセージを永続的に記憶して、メッセージ記憶通知をスレーブノードへ送信するように構成される。
スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる。
スレーブノードユニット2703:ノード200がスレーブノードの状態にある場合に、受信されたメッセージ記憶通知の電子署名を検証した後、受信されたメッセージを永続的に記憶するように構成され、メッセージは、クライアントが異常ノードを決定するために用いられる。
一実施形態において、スレーブノードユニット2703は、ノード200がスレーブノードの状態にある場合に、マスターノードから送信されたメッセージを受信し、結果をクライアントへ返信し、受信されたメッセージの電子署名を検証した後、受信確認通知をマスターノードへ送信し、そして、受信されたメッセージ記憶通知の電子署名を検証した後、受信されたメッセージを永続的に記憶する操作を実行するように構成される。
一実施形態において、ノード200がスレーブノードの状態にある場合に、スレーブノードからクライアントに返信された結果に、メッセージの一意のフィールド、スレーブノードの電子署名の情報が携帯されており、結果は、前記クライアントが携帯された電子署名を検証し、結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定するために用いられる。
一実施形態において、ノード200がスレーブノードの状態にある場合に、スレーブノードから返信された結果に、スレーブノードの受信したメッセージの配列番号が携帯されており、結果に携帯された配列番号は、クライアントが受信された結果に携帯された配列番号と送信されたメッセージの配列番号とを比較し、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、マスターノードが悪意のあるノードであると判定するために用いられる。
一実施形態において、切替ユニット2704をさらに備え、切替ユニット2704は、クライアントが、マスターノードが悪意のあるノードであると決定し、或いは、スレーブノードに障害ノードが存在すると決定した場合に、クライアントのトリガーに応えて第2のコンセンサスモードに切り替えるように構成される。
一実施形態において、切替ユニット2704は、さらに、ノード200が第2のコンセンサスモードに切り替える準備段階にあるときに、以下の操作を実行するように構成される。
ノード200に永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノード(即ち、分散システムにおけるノード200を除いたノード)に永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、一致性確認をクライアントへ送信し、一致性確認に、対応するノードの電子署名が携帯されており、クライアントが一致性確認を受信するときに検証するために用いられる。
クライアントが所定の時間内に全てのノードの一致性確認を受信した場合に、クライアントの通知に応えて第1のコンセンサスモードに切り替える。
クライアントが所定の時間内には全てのノードの一致性確認を受信していない場合に、クライアントの通知に応えて継続して第2のコンセンサスモードに切り替える。
一実施形態において、切替ユニット2704は、さらに、ノード200が第2のコンセンサスモードに切り替える準備段階にあるときに、以下の操作を実行するように構成される。
ノードに永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノード(即ち、分散システムにおけるノード200を除いたノード)に永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、メッセージの送信ノードへデータ確認を送信し、データ確認は、対応するノードの電子署名が携帯されている。
データ確認は、クライアントが、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードが他のノードから送信されたデータ確認を受信していない場合に、分散システムのノードが継続して第2のコンセンサスモードに切り替えるようにトリガーするために用いられる。
一実施形態において、マスターノードユニット2702は、さらに、ノード200がマスターノードの状態にあるとともに、第2のコンセンサスモードにおいて受信したメッセージに関してスレーブノードと合意形成した回数がマスターノードの合意形成回数の閾値を超えたと統計した場合に、スレーブノードとともに第1のコンセンサスモードに切り替えるように構成される。
一実施形態において、マスターノードユニット2702は、さらに、第2のコンセンサスモードにおいて統計した回数であって、受信したメッセージに関してスレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、第1のコンセンサスモードに切り替える旨の通知をスレーブノードへ送信し、全てのスレーブノードから送信された切替確認を受信した場合に、スレーブノードと同期して第1のコンセンサスモードに切り替えるように構成される。
一実施形態において、スレーブノードユニット2703は、さらに、ノードがスレーブノードの状態にある場合に、第1のコンセンサスモードに切り替える旨の通知を受信したときに、受信したメッセージに関して合意形成した回数を統計し、統計した回数がスレーブノードの合意形成回数の閾値を超えた場合に、切替確認をマスターノードへ送信する操作を実行するように構成される。
一実施形態において、投票ユニット2701は、さらに、マスターノードの心拍情報を受信していない場合に、或いは、マスターノードが悪意のあるノードである場合に、分散システムにおけるノード(即ち、分散システムにおけるノード200を除いたノード)とともに投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される。
一実施形態において、投票ユニット2701は、さらに、新しいコンセンサス周期が到来し、かつ分散システムにおけるノードから送信された心拍情報を受信していない場合に、分散システムにおけるノードへ投票要求を送信し、投票要求に、ノードの電子署名が携帯されており、所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換し、心拍情報を分散システムにおけるノードへ定期的に送信することで、マスターノードの状態を保持するように構成され、投票確認は、分散システムにおけるノードが投票要求に携帯された電子署名を検証した後に送信される。
投票ユニット2701は、さらに、新しいコンセンサス周期が到来し、かつ分散システムにおけるノードから送信された心拍情報を受信した場合に、スレーブノードの状態に変換するように構成される。
分散システムにおいて、クライアントは、ハードウェア、及びハードウェアに配置されるソフトウェア環境の組み合わせであることができ、これに基づいて、クライアントはクライアント機器と呼ばれることもでき、マイニング、管理ノード、配置されるスマートコントラクト等の機能を実現するように構成される。
図3Bを参照すると、図3Bは、本発明の実施形態のクライアントの1つの任意的なソフトウェア・ハードウェア構造模式図であり、クライアント300は、ハードウェア層、駆動層、操作システム層およびアプリケーション層を含む。図3Bに示されるクライアント300の構造は一例に過ぎず、クライアント300の構造を限定していないことは当業者に理解されるべきである。例えば、クライアント300は、実施のニーズに応じて図3Bよりも多い構成要素を設けるか、或いは、実施のニーズに応じて一部の構成要素を省略してもよい。
クライアント300のハードウェア層は、プロセッサ310、入出力インターフェース340、記憶媒体330およびネットワークインターフェース320を含み、その構成要素はシステムバスを介して接続されて通信できる。
プロセッサ310は、CPU、MCU、ASIC又はFPGAを用いて実現されることができる。
入出力インターフェース340は、例えば表示画面、タッチパネル、スピーカ等の入出力デバイスを用いて実現されることができる。
記憶媒体330は、フラッシュメモリ、ハードディスク、光ディスク等の不揮発性記憶媒体を用いて実現されることができれば、DDRを用いて実現されることもでき、上述した通信状態処理方法を実行するための実行可能な命令を記憶している。
ネットワークインターフェース320は、プロセッサ310のために外部データへのアクセス能力、例えば、遠隔地に設けられた記憶媒体330へのアクセス能力を提供し、一例として、ネットワークインターフェース320は、例えば、CDMA、WCDMA(登録商標)等の通信方式及その進化方式に基づく通信を実現できる。
駆動層は、システム360がハードウェア層を認識し、ハードウェア層の各構成要素と通信するためのミドルウェア350を含み、例えば、ハードウェア層の各構成要素に対する駆動プログラムの集まりであることができる。
操作システム360は、ユーザに向けたグラフィカルインタフェースを提供し、ブロックチェーンに基づく様々なアプリケーション処理の様々な中間結果と最終結果を表示するように構成される。
アプリケーション層は、分散システムのノードへメッセージを送信し、各ノードにメッセージに対する合意を達成させてメッセージを永続的に記憶させるように構成され、また、分散システムにおける異常ノードを検出し、ノードがコンセンサスモードを切り替えることをトリガーする。
アプリケーション層に関して例を挙げれば、図3Bを参照すると、図3Bは、クライアント300のアプリケーション層の機能構造を提供し、管理ノード380、配置されるスマートコントラクト390およびコンセンサス370を含む。
コンセンサス370に関して例を挙げれば、以下を備える。
通信ユニット3701:クライアントの電子署名が携帯されているメッセージを分散システムのノードのうちのマスターノードへ送信するように構成される。
電子署名は、マスターノードが検証するのに用いられ、受信されたメッセージはマスターノードの電子署名を携帯されて、分散システムにおけるスレーブノードへ送信する。
通信ユニット3701:スレーブノードがメッセージを受信したときに返信した結果を受信するように構成される。
検出ユニット3702:スレーブノードがメッセージを受信したときに返信した結果に基づいて、分散システムにおける異常ノードを決定するように構成される。
一実施形態において、検出ユニット3702は、さらに、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定するように構成される。
一実施形態において、検出ユニット3702は、さらに、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、マスターノードが悪意のあるノードであると判定するように構成される。
一実施形態において、切替ユニット3703をさらに備え、切替ユニット3703は、マスターノードが悪意のあるノードであると決定した場合に、或いは、スレーブノードに障害ノードが存在すると決定した場合に、分散システムにおけるノードが第2のコンセンサスモードに切り替えることをトリガーする。
一実施形態において、切替ユニット3703は、さらに、所定の時間内に全てのノードの一致性確認を受信した場合に、全てのノードが第1のコンセンサスモードに戻るように通知し、所定の時間内には全てのノードの一致性確認を受信していない場合に、全てのノードが継続して第2のコンセンサスモードに切り替えるように通知する。
前記一致性確認に、前記ノードの電子署名が携帯されており、前記ノードが前記第2のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ送信される前に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とが一致すると確認する。
一実施形態において、切替ユニット3703は、さらに、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードが他のノードから送信されたデータ確認を受信していない場合に、分散システムにおけるノードが継続して第2のコンセンサスモードに切り替えることをトリガーする。
データ確認は、対応するノードの電子署名を携帯しており、ノード200が前記第2のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ送信される前に、ノード200に永続的に記憶されたメッセージのハッシュ値と、分散システムにおけるノード(即ち、分散システムにおけるノード200を除いたノード)に永続的に記憶されたメッセージのハッシュ値とが一致すると確認する。
本発明の実施形態に提供される分散システムの場合、ノードは、第1のコンセンサスモードを用いてクライアントからのメッセージに関して合意形成し、第1のコンセンサスモードは、ノードの合意形成効率を保証でき、もちろん、本発明の実施形態では、分散システムのノードがデフォルトに第2のコンセンサスモードを用いてクライアントからのメッセージに関して合意形成することは排除されない。
第1のコンセンサスモードにおいて合意形成する実現形態に関して説明し、図5を参照すると、図5は、本発明の実施形態に提供される分散システムのノードが第1のコンセンサスモードにおいて合意を達成し、障害ノードおよび悪意のあるノードを検出する1つの任意的なフロー模式図であり、ステップ101〜ステップ108を結合して説明する。
ステップ101:分散システムの複数のノードは、第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあること、及びスレーブノードの状態にあることが決定される。
一実施形態において、分散システムのノードは、競合ノード、マスターノード及びスレーブノードという3つのタイプ(状態とも呼ばれる)を有する。分散システムの各ノードはタイマーをスタートし、合意形成するための新しいコンセンサス周期が到来した場合に、各ノードはいずれも競合ノードであり、各競合ノードは、投票操作を実行することで、マスターノード(1つの分散システムにおいて、正規なマスターノードが1つしかない)に変換しようと努力し、マスターノードになっていない競合ノードはスレーブノードに変換する。
各競合ノードは、新しいコンセンサス周期が開始するときに、他のノードから送信された心拍情報を受信したか否かを検出し、受信していなければ、現在のコンセンサス周期内にはまだマスターノードが発生していないことが分かり、この競合ノードは、他のノードへ投票要求を送信し、投票要求に送信ノードの電子署名が携帯され、受信ノードは、投票要求の電子署名の検証に成功した後、投票要求の信頼性を決定し、即ち、送信ノードへ投票確認を送信し、1つのノードが他のノードの投票確認を充分に(例えば、所定数は、半数のノードであることができる)受信していれば、マスターノードに変換し、他のノードへ心拍情報を周期的に送信し、心拍情報を受信した競合ノードはスレーブノードに変換する。1つのコンセンサス周期内にいずれのノードも充分な投票確認を受信していなければ、新しいコンセンサス周期が開始し、マスターノード及びスレーブノードが決まるまで投票操作を継続する。
第1のコンセンサスモードでRAFTアルゴリズムを用いることを例として、図4を参照すると、図4は、本発明の実施形態に提供される第1のコンセンサスモードにおいて各ノードが投票操作を実行することでマスターノード及びスレーブノードを決定する1つの任意的な模式図である。
分散システムにおいて、任意のノードは任意の時刻でマスターノード、スレーブノード及び競合ノードという3つの状態のうちのいずれかの状態にある。分散システムが通常に運転するほとんどの時間内に、分散システムに1つのマスターノードが存在し、他のノードはいずれもスレーブノードであり、マスターノードがクライアントのメッセージを受信する。
分散システムの動作時間は、連続するコンセンサス周期に分けられ、ここで、任期(Term)とも呼ばれ、各任期は、任意の時間長であってもよく、任期は、連続する整数で番号を付けられる。各任期で、まず最初にマスターノード投票を行い、投票段階において、複数の競合ノードがマスターノードとなるように競合し、あるノードがマスターノードになれば、他の競合ノードがスレーブノードに変換し、マスターノードとなったノードは、この任期内に一貫してマスターノードを担い、このマスターノードに障害が生じたら、他のノードは新しい任期内に投票を行う。
任意の任期でも複数のマスターノードが存在することは不可能であり(悪意のあるノードがマスターノードになりすますことを除く)、個々のノードは現在任期のカウント数を維持し、ノード間で通信を行うたびに、任期のカウント数が含まれ、各ノードは、自分の維持している任期カウント数が他のノードの維持している任期カウント数よりも低いと検出した場合に、自分の任期カウント数が検出された最高値となるように更新する。
現在、あるコンセンサス周期におけるマスターノード及び競合ノードは、自分の任期カウント数が他のノードの任期カウント数よりも低いことが判明した場合に、すぐに自分をスレーブノードに変換し、これにより、1つの任期内に1つのマスターノードしかないことを保証する。
RAFTアルゴリズムでは、心拍メカニズムを用いてマスターノードの投票操作をトリガーし、分散システムが起動する際に、全てのノードがスレーブノード状態に初期化し、任期を0に設定するとともに、タイマーをスタートし、タイマーがタイムアウトした後、スレーブノードが競合ノードに変換し、競合ノードに変換すると、以下の操作を実行する。
ステップ1011:ノードの任期のカウント数を増やす。
ステップ1012:新しいタイマーをスタートする。
ステップ1013:他のノードへ投票要求(Request Vote)遠隔手続き呼出しプロトコル(RPC、Remote Procedure Call Protocol)メッセージを送信し、他のノードが投票確認を返信するのを待つ。
タイマーがタイムアウトする前に、多くのノードから投票確認を受信していれば、マスターノードに変換する。他のノードから送信された追加内容がアイドルである追加入口(Append Entries)心拍RPCメッセージを受信していれば、他のノードがマスターノードとして選ばれたことが分かり、スレーブノードに変換する。タイマーがタイムアウトしても上記2つの情報も受信していなければ、新しい投票操作を行う。
ノードは、多くのノードの投票を受けてマスターノードになった後、すぐに全てのノードへAppend Entries心拍RPCメッセージを送信し、競合ノードがAppend Entries心拍RPCメッセージを受信した後、スレーブノードに変換し、投票操作が終了する。
ステップ102:クライアントは、メッセージに対して電子署名を行い、電子署名が携帯されているメッセージをマスターノードへ送信する。
クライアントは、自分の秘密鍵を用いてメッセージのダイジェスト(本発明の実施形態では、任意のダイジェストアルゴリズムを用いてメッセージからダイジェストを抽出することは排除しない)を暗号化し、電子署名を形成する。
ステップ103:マスターノードは、メッセージの電子署名の検証に成功した後、メッセージにマスターノードの電子署名を追加して、メッセージをスレーブノードへ送信する。
マスターノードは、公開鍵を用いて電子署名を復号してダイジェストを得て、ダイジェストアルゴリズム(クライアントの使用するダイジェストアルゴリズムと一致する)を用いたものと照合し、一致していれば、メッセージの由来が信頼できることが分かり、マスターノードの秘密鍵を用いてメッセージのダイジェストを暗号化してマスターノードの電子署名を形成し、メッセージにマスターノードの電子署名を追加して各スレーブノードへ送信する。メッセージに携帯されたクライアントの電子署名は、携帯されても携帯されなくてもよい。マスターノードが照合した結果、一致していなければ、メッセージを破棄してクライアントに対して再伝送するように要求できる。
ステップ104:スレーブノードは、マスターノードから送信されたメッセージを受信した後、受信されたメッセージの電子署名を検証し、検証が通過した後、受信確認通知をマスターノードへ送信し、結果をクライアントへ送信する。
スレーブノードは、公開鍵を用いて受信されたメッセージの電子署名を復号してダイジェストを得て、ダイジェストアルゴリズム(マスターノードの使用するダイジェストアルゴリズムと一致する)を用いたものと照合し、一致していれば、メッセージの由来が信頼できることが分かり、スレーブノードの秘密鍵を用いて受信確認通知のダイジェストを暗号化してスレーブノードの電子署名を形成し、マスターノードへ返信する。
スレーブノードが結果をクライアントへ送信することは、2つの場合を含む。
1)現在のコンセンサス周期内において、スレーブノードが、マスターノードから送信されたメッセージを初めて受信していれば、クライアントへ送信する結果は、受信されたメッセージの配列番号と、メッセージの一意のフィールド(メッセージにおけるフィールドであり、他のメッセージのフィールドと区別できる)と、スレーブノードの秘密鍵を用いて結果のダイジェストを暗号化して得た、スレーブノードの結果に対する電子署名と、が含まれている。
2)現在のコンセンサス周期内において、スレーブノードがマスターノードから送信されたメッセージを受信したことが初めてではなければ、クライアントへ送信する結果に、メッセージの一意のフィールド(メッセージにおけるフィールドであり、他のメッセージのフィールドと区別できる)と、スレーブノードの秘密鍵を用いて結果のダイジェストを暗号化して得た、スレーブノードの結果に対する電子署名と、が含まれている。
ステップ105:マスターノードは、受信された受信確認通知に携帯された電子署名を検証し、所定数のスレーブノードから送信された受信確認通知を連続して受信した後、メッセージを永続的に記憶し、メッセージ記憶通知をスレーブノードへ送信する。
メッセージ記憶通知に、マスターノードのメッセージ記憶通知に対する電子署名が携帯されており、電子署名は、マスターノードの秘密鍵を用いてメッセージ記憶通知のダイジェストを暗号化して得たものである。
永続的な記憶の場合に、マスターノードは、メッセージを不揮発的に記憶し、例えば、ブロックチェーンシステムにおいて、クライアントのコミットした取引履歴を受信したノード(マスターノード)は、取引履歴をブロックチェーンの新しいブロックに記憶する。
ステップ106:スレーブノードがメッセージ記憶通知を受信し、携帯された電子署名の検証に成功した後、スレーブノードのローカルにメッセージを永続的に記憶し、電子署名が携帯されているメッセージ記憶確認をマスターノードへ送信する。
スレーブノードは、公開鍵を用いて、受信されたメッセージ記憶通知の電子署名を復号してダイジェストを得て、ダイジェストアルゴリズム(マスターノードの使用するダイジェストアルゴリズムと一致する)を用いたものと照合し、一致していれば、メッセージ記憶通知の由来が信頼できることが分かり、スレーブノードの秘密鍵を用いてメッセージ記憶確認のダイジェストを暗号化してスレーブノードの電子署名を形成し、電子署名が携帯されているメッセージ記憶確認をマスターノードへ返信する。
ステップ107:マスターノードは、受信されたメッセージ記憶確認の電子署名を検証し、半数を超えたスレーブノードのメッセージ記憶確認を受信し、電子署名の検証に成功していれば、クライアントへメッセージ記憶確認を送信する。
マスターノードからクライアントへ送信されたメッセージ記憶確認は、マスターノードの電子署名を携帯しており、クライアントが、記憶されたメッセージの由来の信頼性を検証するために用いられる。
ステップ108:クライアントは、マスターノード及びスレーブノードがメッセージを受信したときに返信した結果に基づいて、異常ノードを検証し、マスターノードが悪意のあるノードであるか否かを決定するとともに、スレーブノードに障害ノードが存在するか否かを決定する。
一実施形態において、クライアントは、各スレーブノードから返信された結果(各スレーブノードがマスターノードから送信されたメッセージを受信した後に送信される)の電子署名の検証に成功した後、受信された結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致していなければ、一致しない一意のフィールドを送信したスレーブノードをエラーノードとして判定し、結果を返信していないスレーブノードを障害ノードとして判定する。
一実施形態において、マスターノードが1つの新しいコンセンサス周期内に新たに発生したマスターノードである場合に、このマスターノードから送信されたメッセージを受信したときに、スレーブノードからクライアントへ送信された結果に、一意のフィールド及び電子署名に加え、受信されたメッセージの配列番号も含まれ、これにより、クライアントは、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が数の閾値を超えた場合に、新たに発生したマスターノードがスレーブノードへ偽造メッセージを送信したことが分かるため、マスターノードが悪意のあるノードであると判定する。
上述したステップから分かるように、第1のコンセンサスモードにおいて、
1)電子署名の方式を用いることで通信の信頼性を保証する。
任意の通信を行う双方はそれぞれ電子署名の方式を利用し、即ち、送信側はメッセージを送信する際にメッセージの電子署名を携帯させ、例えば、送信側の非対称暗号化アルゴリズムの秘密鍵を用いてメッセージのダイジェストを暗号化し、送信側の電子署名を形成し、受信側は、電子署名を検証することでメッセージの信頼性を保証し、即ち、メッセージの署名を読んで、非対称暗号化アルゴリズムの公開鍵(受信側及び送信側が同じ非対称暗号化アルゴリズムを用いることを保証すれば、受信側は公開鍵を予め取得する)を用いて復号し、復号して得たダイジェストとメッセージから抽出されたダイジェストとを照合し、一致していれば、電子署名の検証が通過し、送信側から送信されたメッセージが信頼できることが分かる。
2)スレーブノードは、マスターノードから送信されたメッセージを受信するときに、結果を直接クライアントへ返信し、結果に、例えば一意のフィールド、メッセージ配列番号及び電子署名等の必要な情報が携帯され、このように、クライアントは、直接スレーブノードから返信された結果に基づいてスレーブノードの合意達成状況を判定でき、異常ノードを容易に検出できる。
第1のコンセンサスモードにおいて異常ノードを検出した場合に、第1のコンセンサスモードは、ノードの合意形成効率を保証することに適するが、ノードの異常に対するフォールトトレランス性能は限られているため、本発明の実施形態は、分散システムにおいて異常ノードが発生したときに、分散システムが優れたフォールトトレランス性能を有する第2のコンセンサスモードに切り替えるようにするソリューションを提供する。
図6を参照すると、図6は、本発明の実施形態に提供される分散システムが第1のコンセンサスモードと第2のモード間を切り替える1つの任意的なフロー模式図であり、ステップ109〜ステップ112を結合して説明する。
ステップ109:クライアントは、分散システムに異常ノードが存在すると決定した場合に、分散システムにおけるノードが第2のコンセンサスモードに切り替えることをトリガーする。
マスターノードが悪意のあるノードであり、スレーブノードに障害ノードが存在し、或いは、スレーブノードに異常ノードが存在する場合に、クライアントは、分散システムのノードへ、第2のコンセンサスモードに切り替える旨の通知を放送する。
ステップ110:分散システムのノードは、第2のコンセンサスモードに切り替える準備段階において、対応するノードに永続的に記憶されたメッセージのハッシュ値及び電子署名を他のノードへ送信する。
ノード200を例として、ノード200は、第2のコンセンサスモードに切り替える準備段階において、ノード200に永続的に記憶されたメッセージのハッシュ値及び電子署名を分散システムにおけるノード200を除いたノードへ送信する。
ステップ111:メッセージの受信ノードは、分散システムにおける他の全てのノード(即ち、受信ノードを除いた全てのノード)から送信されたハッシュ値及び電子署名を全て受信し、ハッシュ値の電子署名の検証に成功した後、そのハッシュ値と受信ノードに永続的に記憶されたメッセージのハッシュ値とを比較し、全てが一致していれば、クライアントへ一致性確認を送信する。
例えば、分散システムにおける通知を受信したノード1は、第2のコンセンサスモードに切り替える準備段階において、ノードに永続的に記憶されたメッセージのハッシュ値及び電子署名をノード2−N(Nは、分散システムにおけるノードの数である)へ送信(例えば、放送)し、同時に、ノード1は、ノード2〜ノードNから送信されたハッシュ値を受信し、ハッシュ値には対応するノードの電子署名が携帯されており、ノード1は電子署名の検証に成功した後、ノード2〜ノードNから送信されたハッシュ値とノード1に永続的に記憶されたメッセージのハッシュ値とを比較し、全てが一致していれば、ノード1はクライアントへ一致性確認を送信する。
ノード2〜ノードNに関して、ハッシュ値を受信した処理はノード1に類似し、その説明を繰り返さない。
ステップ112:クライアントは、全てのノードの一致性確認を受信したか否かを検出し、YESであれば、分散システムのノードが継続して第1のコンセンサスモードに切り替えるように通知し、NOであれば、分散システムのノードが継続して第2のコンセンサスモードに切り替えるように通知する。
クライアントが分散システムにおける全てのノードから送信された一致性確認を受信していれば、その前に異常ノードを検出したのは、ネットワークの変動又は応答メッセージを破棄したことによるものであり、分散システムに異常ノードが存在しないことが分かり、このため、再び第1のコンセンサスモードに切り替え、ノード間での合意形成効率を保証する。
クライアントは所定の時間内には分散システムにおける全てのノードから送信された一致性確認を受信していなければ、分散システムに確かに異常ノードが存在することが分かり、分散システムにおけるノードが継続して第2のコンセンサスモードへの切り替えを保持するように通知する。
図7を参照すると、図7は、本発明の実施形態に提供される分散システムが第1のコンセンサスモードと第2のモード間を切り替える1つの任意的なフロー模式図であり、以下のステップ113〜ステップ116を含む。
ステップ113:クライアントは、分散システムに異常ノードが存在すると決定した場合に、分散システムにおけるノードが第2のコンセンサスモードに切り替えることをトリガーする。
マスターノードが悪意のあるノードであり、スレーブノードに障害ノードが存在し、或いは、スレーブノードに異常ノードが存在する場合に、クライアントが分散システムのノードへ第2のコンセンサスモードに切り替える旨の通知を放送する。
ステップ114:分散システムのノードは、第2のコンセンサスモードに切り替える準備段階において、対応するノードに永続的に記憶されたメッセージのハッシュ値及び電子署名を他のノードへ送信する。
ステップ115:メッセージの受信ノードが分散システムにおける他のノードから送信されたハッシュ値及び電子署名を受信し、ハッシュ値の電子署名の検証に成功した後、そのハッシュ値と受信ノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致していれば、メッセージの送信ノードへデータ確認を送信する。
例えば、分散システムにおける通知を受信したノード1は、第2のコンセンサスモードに切り替える準備段階において、ノードに永続的に記憶されたメッセージのハッシュ値及び電子署名をノード2−N(Nは、分散システムにおけるノードの数である)に送信(例えば、放送)し、同時に、ノード1は、ノード2〜ノードNから送信されたハッシュ値を受信し、ハッシュ値に、対応するノードの電子署名が携帯されており、ノード1は電子署名の検証に成功した後、ノード2〜ノードNから送信されたハッシュ値とノード1に永続的に記憶されたメッセージのハッシュ値とを比較し、全てが一致していれば、ノード1は、ノード2〜ノードNへそれぞれデータ確認を送信する。
ノード2〜ノードNに関して、ハッシュ値を受信した処理はノード1に類似し、その説明を繰り返さない。
ステップ116:クライアントは、各ノードから送信されたデータ確認に基づいて、分散システムのノードが第1のコンセンサスモードに戻るようにトリガーするか、或いは、分散システムのノードが継続して第2のコンセンサスモードに切り替えるようにトリガーする。
分散システムの各ノードにとって、ノードに永続的に記憶されたメッセージのハッシュ値及び送信ノードの電子署名を他のノードへ放送する。ハッシュ値の受信ノードにとって、受信されたハッシュ値の電子署名を検証した後、受信されたハッシュ値と受信ノードに記憶されたメッセージのハッシュ値とを比較し、比較した結果、一致する場合に、対応するハッシュ値の送信ノードへ、2つのノードに記憶されたメッセージが一致することを示すデータ確認を送信する。
ここで、2つの場合がある。
場合1):所定の時間内に、データ確認の受信ノードは、いずれも他のノード(受信ノードを除いたノード)から送信されたデータ確認を受信していれば、クライアントへデータ確認を送信でき、クライアントは、データ確認に基づいて、各ノードに記憶されたメッセージが一致すると確認し、継続して第2のコンセンサスモードに切り替える必要がないため、分散システムの各ノードへ第1のコンセンサスモードに戻る旨の通知を送信でき、第2のコンセンサスモードに切り替えるプロセスが終了する。
例えば、ノード1はノード2〜ノードNへハッシュ値を送信し、ハッシュ値にノード1の電子署名が携帯され、ノード2〜ノードN−1は、ノード1の電子署名の検証に成功した後、ノード2を例として、ノード2は、ノード2に永続的に記憶されたメッセージのハッシュ値(ブロックチェーンシステムにおけるノードにとって、ブロックチェーンにおける最新のブロックのハッシュ値であることができる)とノード1から送信されたハッシュ値とを比較し、一致していれば、ノード1へデータ確認を送信し、ノード3〜ノードN−1に関しての処理はノード2に類似する。
仮にノード1はノード2〜ノードN−1のデータ確認を受信したが、ノードNのデータ確認を受信していなければ、クライアントは所定の時間内にはノード1のデータ確認を受信していないため、クライアントは、ノード1のデータが全ての他のノードのデータと一致していないと認め、ノード1〜ノードNが第2のコンセンサスモードに切り替える操作を継続するように通知する。
場合2):所定の時間内にいずれのノードが他のノードのデータ確認を受信していない場合に、或いは、所定の時間内に合意したノードが合意していないノードのデータ確認を受信していないため、クライアントが他のノードのデータ確認を受信していない場合に、クライアントは、分散システムにおけるノードが継続して第2のコンセンサスモードに切り替えるように通知する。
例えば、ノード1はノード2〜ノードNへハッシュ値を送信し、ハッシュ値にノード1の電子署名が携帯され、ノード2〜ノードN−1は、ノード1の電子署名の検証に成功した後、ノード2を例として、ノード2は、ノード2に永続的に記憶されたメッセージのハッシュ値(ブロックチェーンシステムにおけるノードにとって、ブロックチェーンにおける最新のブロックのハッシュ値であることができる)とノード1から送信されたハッシュ値とを比較し、一致していれば、ノード1へデータ確認を送信し、ノード3〜ノードN−1に関しての処理はノード2に類似する。
仮にノード1は、所定の時間内にノード2〜ノードN−1のデータ確認を受信したが、ノードNのデータ確認を受信していなければ、所定の時間内には他のノードのデータ確認を全て受信していない旨の通知をクライアントへ送信し、クライアントは、ノード1〜ノードNが第2のコンセンサスモードに切り替える操作を継続するように通知する。
さらに、例えば、ノード1はノード2〜ノードNへハッシュ値を送信し、ハッシュ値にノード1の電子署名が携帯され、ノード2〜ノードN−1は、ノード1の電子署名の検証に成功した後、ノード2を例として、ノード2は、ノード2に永続的に記憶されたメッセージのハッシュ値(ブロックチェーンシステムにおけるノードにとって、ブロックチェーンにおける最新のブロックのハッシュ値であることができる)とノード1から送信されたハッシュ値とを比較し、一致していれば、ノード1へデータ確認を送信し、ノード3〜ノードN−1に関しての処理は、ノード2に類似する。
仮にノード1は、所定の時間内にノード2〜ノードN−1のデータ確認を受信したが、ノードNのデータ確認を受信していなければ、ノード1は他のノード(つまり、分散システムにおけるノード1を除いたノード)のデータ確認を全て受信していない旨の通知をクライアントへ送信し、クライアントは、ノード1〜ノードNが第2のコンセンサスモードに切り替える操作を継続するように通知する。
引き続き、分散システムのノードが第2のコンセンサスモードに切り替え、第2のコンセンサスモードから第1のコンセンサスモードに切り替える方式に関して説明し、第2のコンセンサスモードから第1のコンセンサスモードに戻る方式は、以下のいくつかある。
方式1):マスターノードは、合意形成回数がマスターノードの合意形成回数の閾値を超えたと統計した場合に、スレーブノードが第1のコンセンサスモードに切り替えることをトリガーし、マスターノード及びスレーブノードは、第1のコンセンサスモードに切り替えるときに、第2のコンセンサスモードにおけるノード状態を継承する(即ち、ノードがマスターノード又はスレーブノードである状態は変わらないままである)。
分散システムが第2のコンセンサスモードにあるときに、分散システムにおけるマスターノード(ここでのマスターノードは1つのコンセンサス周期に対するものであることは理解されることができる)にとって、マスターノードが第2のコンセンサスモードにおいて、受信したメッセージに関してスレーブノードと合意形成する回数がマスターノードの合意形成回数の閾値を超えた(例えば、M回であり、Mは、分散システムにおけるノードの合意精度に基づいて設定され、一般的には、精度要求が高ければ、所定回数が大きくなり、両者は正の相関関係を有する)と統計していれば、マスターノードとスレーブノードが、クライアントから連続して送られるメッセージに関してよく合意を達成していることが分かり、分散システムのノードの合意形成効率をさらに向上させるために、第1のコンセンサスモードに切り替える旨の通知をスレーブノードへ送信できる。
分散システムにおけるスレーブノードは、マスターノードから送信された第1のコンセンサスモードに切り替える旨の通知を受信した後、切替確認をマスターノードへ送信し(マスターノードが第1のコンセンサスモードに切り替えるときにマスターノードの状態を継続して保持することを承認する)、マスターノード及びスレーブノードは現在のノード状態を保持したまま第1のコンセンサスモードに切り替え、このように、第1のコンセンサスモードにおいて悪意のあるノードがマスターノードとなることを回避でき、合意形成効率を確保する。
上述の合意したノード数の閾値は、分散システムにおける全てのスレーブノードの数であるか、或いは、分散システムにおいて第1のコンセンサスモードで合意形成することを求められるスレーブノードの数の最小値(即ち、第1のコンセンサスモードのフォールトトレランス性能に求められる合意したノード数の最小値であり、最小値よりも低ければ、第1のコンセンサスモードで達成した合意の信頼性は保証されることができない)であることができる。
同様に、上述の合意したノード割合閾値は、分散システムにおける全てのスレーブノードの数に対応し、例えば100%であるか、或いは、分散システムにおいて第1のコンセンサスモードで合意形成することを求められるスレーブノードの数の最小値、例えば、51%(即ち、第1のコンセンサスモードのフォールトトレランス性能に求められる合意したノード数の最小値であり、この最小値よりも低ければ、第1のコンセンサスモードで達成した合意の信頼性は保証されることができない)であることができる。
例えば、分散システムが第2のコンセンサスメカニズムにあり、仮にノード1をマスターノードとし、ノード2〜ノードNをスレーブノードとすると、各ノードがクライアントからのメッセージに関して合意形成することをカウントし、ノード1にとって、ノード1とノード2〜ノードNは、最近クライアントから送られたM個(マスターノードの合意形成回数の閾値)のメッセージのそれぞれに関して合意を達成していれば、各ノード間でよく合意を達成したことが示され、ノード1は第1のコンセンサスモードに切り替える旨の通知をノード2〜ノードNへ送信し、ノード2〜ノードNはノード1へ切替確認を送信し、ノード1が第1のコンセンサスモードにおいてもマスターノードであることを承認して、ノード2〜ノード2Nが継続してスレーブノードであり、ノード2〜ノードNにおいて悪意のあるノードが生じても、クライアントからのメッセージを偽造できず、ノードの合意形成効率を確保する。
方式2):マスターノードは、合意形成回数がマスターノードの合意形成回数の閾値を超えたと統計した場合に、マスターノードは、スレーブノードが第1のコンセンサスモードに戻ることをトリガーし、スレーブノードは、合意形成回数の閾値がスレーブノードの合意形成回数の閾値を超えたと統計した場合に、スレーブノードは、第1のコンセンサスモードに戻ることを確認し、マスターノード及びスレーブノードは、第1のコンセンサスモードに切り替えるときに第2のコンセンサスモードにおけるノード状態を継承する(即ち、ノードがマスターノード又はスレーブノードである状態は変わらないままである)。
分散システムが第2のコンセンサスモードにあるときに、マスターノードは、第2のコンセンサスモードにおいてクライアントからのメッセージに関して他のノード(マスターノード及び他のスレーブノードを含む)と合意形成する回数を統計し、合意形成回数がスレーブノードの合意形成回数の閾値を超えていれば(マスターノードの合意形成回数の閾値以下であってもよく、例えば、M/2であることができる)、マスターノードが第1のコンセンサスモードにおいて継続してマスターノードであることに同意する旨の通知をマスターノードへ送信し、第2のコンセンサスモードにおけるスレーブノードは、第1のコンセンサスモードに切り替えるときに継続してスレーブノードであり、これにより、第1のコンセンサスモードに切り替える投票操作を完成し、継続して第1のコンセンサスモードにおいてクライアントからのメッセージに関して合意形成する。このように、第1のコンセンサスモードにおいて悪意のあるノードがマスターノードになることを回避することができ、合意形成効率を確保する。
分散システムのノードが第1のコンセンサスモードに切り替わった後、第1のコンセンサスモードにおいて異常ノードを検出していなければ、継続して第1のコンセンサスモードを保持し、第1のコンセンサスモードに戻った後でもよく合意を達成していなければ(例えば、依然として悪意のあるノード、異常ノード又はエラーノードを検出していれば)、再び第2のコンセンサスモードに切り替える。
ここでの所定数/割合は前の説明に基づいて理解されることができ、その説明を繰り返さない。
例えば、分散システムのマスターノードは、カウンターに基づいて、第2のコンセンサスモードに切り替わることと同期して計時を開始でき、計時時間が計時時間閾値(例えば、10分間)に達した後、分散システムのスレーブノードが同期して第1のコンセンサスモードに戻るようにトリガーし、第1のコンセンサスモードにおいて投票操作を実行することで、新しいマスターノード及びスレーブノードが決定される。第1のコンセンサスモードに切り替わった後でも異常ノードを検出していれば、再び第2のコンセンサスモードに切り替える(第1のコンセンサスモードに切り替える方式は前の説明に基づいて理解されることができる)。これにより、第2のコンセンサスモードを用いて合意形成することで、分散システムのフォールトトレランス性能を保証する前提において、分散システムの合意形成効率を最大限に向上させる。
ここでの所定数/割合は前の説明に基づいて理解されることができ、その説明を繰り返さない。
例えば、分散システムが第2のコンセンサスメカニズムにあり、ノード1をマスターノードとし、ノード2〜ノードNをスレーブノードとすると、各ノードがクライアントからのメッセージに関して合意形成することをカウントし、ノード1にとって、ノード1とノード2〜ノードNは、最近クライアントから送られたM個(マスターノードの合意形成回数の閾値)のメッセージのそれぞれに関して合意を達成していれば、各ノードでよく合意を達成したことが示され、ノード1は、第1のコンセンサスモードに切り替える旨の通知をノード2〜ノードNへ放送し、ノード2〜ノードNにとって、ノード2を例として、ノード2は、第2のコンセンサスモードにおいて合意形成した回数を統計し、M/2を超えていれば、ノード1へ切替確認を送信する(ノード1が第1のコンセンサスモードに切り替える時でもマスターノードであり、ノード2がスレーブノードであることを承認する)。ノード3〜ノードNに関しての処理はノード2に類似し、その説明を繰り返さない。
ノード1は、ノード2〜ノードNのうちのそれぞれのノードから送信された切替確認を受信した場合に、第1のコンセンサスモードに切り替え、第1のコンセンサスモードにおいて、ノード1がマスターノードであり、ノード2〜ノードNがスレーブノードである。ノード1がノード2〜ノードNのうちのそれぞれのノードから送信された切替確認を受信していなければ、継続して第2のコンセンサスモードに留まり、M/2回の合意おきに、ノード1は、ノード2〜ノードNのうちの全てのノードの切替確認を受信するまで、第1のコンセンサスモードに切り替える旨の通知を継続してノード2〜ノードNへ送信する。
以下、ブロックチェーンシステム(例えば、それぞれの個人又はエンティティに開放されるコンソーシアムチェーンシステム)が第1のコンセンサスモードにおいて改良型RAFT(T−RAFT)アルゴリズムを利用し、第2のコンセンサスモードにおいてPBFTアルゴリズムを利用して合意形成することを例として説明するが、第1のコンセンサスモードにおいてPaxosアルゴリズムを利用してもよく、第2のコンセンサスモードにおいてBFTアルゴリズム、BFT−RAFT等を利用してもよいことは理解されることができる。第1のコンセンサスモードでは、合意形成効率が高く、ノードの障害又はビザンチンノードを検出できる任意のアルゴリズム、例えばT−RAFTアルゴリズムを利用でき、第2のコンセンサスモードでは、ビザンチンフォールトトレランスを実現できるアルゴリズムを利用できる。
関連技術に提供されるRAFTアルゴリズムは、複数のノードデータの一致性問題のみを解決しているが、ビザンチンフォールトトレランスを解決していないものの、効率が比較的に高い。PBFTアルゴリズムは、ビザンチンフォールトトレランスを解決できるが、しかし、PBFTアルゴリズムでは、ノードにおいてメッセージ放送を行う必要があるため、実現効率が比較的に低い。
分散ネットワークがコンソーシアムチェーン(それぞれの個人又はエンティティに開放されるブロックチェーン)に適用される使用場面において、一般的には、ブロックチェーンシステムはほとんどの場合、ノードの障害がなければ、ビザンチンノード問題もなく、RAFTのアルゴリズムを利用することでノード間で合意を高効率に形成できる。
関連技術に提供されるRAFTは、複数のノードの一致性問題を解決し、効率が比較に高いが、しかし、ノード間でのビザンチンフォールトトレランス問題を解決しておらず、一方、PBFTアルゴリズムは、複数のノードの一致性を保証できるとともに、各ノード間でのビザンチンフォールトトレランスを解決している。このため、本発明の実施形態では、ノードにエラーが生じた場合に、或いはビザンチン問題が生じた場合に、PBFTアルゴリズムを自動的に用いて各ノード間で合意形成でき、全てのノードがそれぞれ合意を達成し、即ち、ビザンチンノードがない場合に、再び合意形成効率の高いRAFTアルゴリズムに自動的に切り替えて、各ノード間で合意形成する。
図8を参照すると、図8は、発明の実施形態に提供されるブロックチェーンシステムがRAFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図であり、クライアントがメッセージをマスターノード(leaderノード)へ送信した後、マスターノードは、受信されたメッセージを並び替え、並び替える順に従ってスレーブノード(followerノード)に配布し、他のfollowerは、leaderノードが並び替えた順に従ってメッセージをログに記憶し、leaderノードへRPC結果(result)を返信し、その後、leaderノードは、ログにおけるメッセージをローカルの磁気ディスクに記憶してから、各スレーブノードへコミット(Commit)を送信し、各スレーブノードは、メッセージにおけるログをスレーブノードのローカル磁気ディスクに記憶すれば、メッセージの一致性を同期させることを完成し、効率が高いが、ビザンチンノード問題を解決できない。
図9を参照すると、図9は、発明の実施形態に提供されるブロックチェーンシステムがPBFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図であり、1つのメッセージは、2回放送された後に正式に確認されることができ、放送に依存するため、合意形成のプロセスで送信されるメッセージ数は、ノード数の2乗となるため、合意形成効率が比較的に低いが、ノード間でのビザンチンフォールトトレランス問題を解決できる。
RAFTアルゴリズムは、一致性問題を解決でき、かつ効率が高いが、ビザンチンフォールトトレランス問題を解決できないため、ブロックチェーンシステムの多くの場面において採用されず、効率が相対的に低いがビザンチンフォールトトレランスを解決できるPBFTアルゴリズムしか採用できない。本発明の実施形態は、コンソーシアムチェーンにおける応用場面では、多くの場合、ネットワーク条件が良好で、かつビザンチンノードがなく、マルチノード間で合意形成できればよいという特徴を十分に活かし、RAFTの高効率およびPBFTのフォールトトレランスの利点を結合して、効率が高いとともに、ビザンチンフォールトトレランス問題を解決できる自己適応型コンセンサスアルゴリズムを提供する。
コンソーシアムチェーンに適用されるブロックチェーンシステムにおいて、合意形成に参加するノード数は限られるとともに、ほとんどの場合、各参加ノードはビザンチンノードがなく、データの一致性を保証すればよく、この場合、効率が高いT−RAFTアルゴリズムを利用する。異常が発生し、例えば、ノード間でビザンチンフォールトトレランスニーズがあるか、或いはノードに障害が発生した場合に、これをタイムリーに検出できるとともに、ビザンチンフォールトトレランスをサポートできるPBFTアルゴリズムに自動的に切り替えることができ、PBFTアルゴリズムにおいて全てのノードが合意した場合に、再び効率の高いT−RAFTアルゴリズムに自動的に切り替え、このように、ほとんどの場合、即ち、ネットワークが良好で、ビザンチンノードがない場合に、コンソーシアムチェーンの高効率な合意形成要求を満たすことができる一方、異常ノードがある場合に、リアルタイムに修正し、フォールトトレランスを実現できる。
コンセンサスアルゴリズムの自動的な切り替えを実現するために、図10を参照すると、図10は、本発明の実施形態に提供される自己適応型コンセンサスアルゴリズムを実現する運転状態図であり、ブロックチェーンシステムは、デフォルトに、T−RAFTアルゴリズムで合意形成し、T−RAFTアルゴリズムによってデータが一致しないノードが閾値よりも低い(全てのノード数、或いは、所定の割合のノードであり、T−RAFTアルゴリズムのフォールトトレランス性能に基づいて設定される)と検出した場合に、以下のようなデータ(メッセージ)の一致性の確認状態に入る。各ノードのデータが一致すると確認していれば、T−RAFTアルゴリズムに戻る。ノードのデータが一致していなければ、PBFTアルゴリズムに変換してノード間での合意を実現する。PBFTアルゴリズムの運転時に全てのノードのデータが一致すると検出していれば、T−RAFTアルゴリズムに切り替える。
T−RAFTアルゴリズムはRAFTアルゴリズムを改良したものであり、ノードによるメッセージの改ざん、メッセージの再生、メッセージの偽造を防止できるとともに、悪意のあるノードをタイムリーに発見できる。図11を参照すると、図11は本発明の実施形態に提供されるT−RAFTアルゴリズムによる合意形成の実現模式図であり、RAFTアルゴリズムに比べ、主に以下の改良点がある。
1.クライアント(Client)から送信されたメッセージに、メッセージのメッセージボディに対する電子署名が携帯されており、これにより、メッセージの伝送中に修正されたりすることを防止でき、そして、メッセージに一意のフィールドが携帯され、メッセージが横取りされた後再生されることを防止できる。
2.各ノード間で伝送されるメッセージに送信側の電子署名が携帯され、メッセージの受信ノードはそれぞれ電子署名の正確性を検証し、これにより、新しいノードが偽造されて投票操作に参加するか、或いは、マスターノードになりすましてスレーブノードへ偽りのメッセージを送信することを防止できる。
3.クライアントが要求をマスターノードへ送信した後、T−RAFTコンセンサスモードにおけるマスターノードがメッセージをスレーブノードへ同期して送信するプロセスにおいて、全てのスレーブノードがマスターノードから送信されたメッセージを受信した後、元のRAFTのメッセージフローを完成する以外に、いずれも結果をクライアントへ返信し、返信された結果に、メッセージにおける一意のフィールド及びスレーブノードの電子署名が携帯されている。このように、クライアントは、全てのノードから返信された結果が一致するか否かを比較することで、各ノードのデータ(メッセージ)の一致性を判断できる。クライアントの受信した結果が一致しないか、或いは、所定の時間内には全てのノードの結果を受信していなければ、ビザンチンノードが存在するか、或いは障害ノードが存在すると判断し、データ一致性確認フローをトリガーする。
データ一致性確認のプロセスは、コンセンサスアルゴリズムを切り替える中間段階に発生し、データ復元のプロセスは、実際には、多数決の合意形成のプロセスであり、合意形成のプロセスではメッセージ放送方式を利用し、具体的には、ノードは、デフォルトにT−RAFTアルゴリズムを利用する。エラーになったノードがある場合に、或いは、ビザンチンノードがある場合に、クライアントは、各ノードから返信された結果を比較することで、データが一致しない状況を発見でき、アルゴリズム切替を行う必要があるか否かを判断する。
例を挙げれば、PBFTアルゴリズムのコンセンサスモードに切り替える必要があれば、クライアントは、PBFTアルゴリズムに切り替える旨の通知を各ノードへ放送し、ノードがコンセンサスアルゴリズム切替通知を受信して準備(Prepare)段階にある場合に、データ要求確認メッセージを全ての他のノードに放送し、データ要求確認メッセージに、ノードのブロックチェーンにおける最近合意形成したブロックのハッシュ値及びノードの電子署名が携帯されている。
データ要求確認メッセージを受信したノードは、ここで「受信ノード」と呼ばれ、ノードのブロックチェーンにおける最新の合意形成したブロックのハッシュ値とデータ要求確認メッセージに携帯されたハッシュ値とが一致するか否かを検査するとともに、ノードの電子署名の正確性を検証し、受信ノードは、全ての他のノードのデータ要求確認メッセージを受信し、これらのデータ要求確認メッセージの署名が正しく、かつ受信ノードの最新の合意形成したブロックのハッシュ値と一致していれば、クライアントへ、受信ノードの電子署名が携帯されているデータ一致性確認を返信する。
クライアントが全てのノードのデータ一致性確認を受信していれば、各ノードの維持したブロックチェーンのデータが一致すると認めるとともに、アルゴリズム切替要求前のデータ一致性照合が失敗したのは、ネットワークの変動又は応答メッセージを破棄したことによるものであると認め、再びT−RAFTアルゴリズムに切り替える。具体的なフローは下記のメッセージフローチャートを参照できる。
一例として、図12を参照すると、図12は、本発明の実施形態に提供されるPBFTアルゴリズムへの切替準備段階においてT−RAFTアルゴリズムに戻る1つの任意的なフロー模式図であり、図12において、ノード1、2、3、4はいずれも他のノードからのデータ一致性確認の放送メッセージを受信しているとともに、各ノードの最新の合意形成したブロックのハッシュ値が一致すると確認し、各ノードはそれぞれデータ一致性確認をクライアントへ返信するとともに、それぞれT−RAFTアルゴリズムの状態を返信し、クライアントが再びT−RAFTに切り替える旨の通知はノードに到達していなくても、ノードはタイムアウト時間が到着した後、T−RAFTアルゴリズムの投票フローに入る。
タイムアウト時間内にクライアントが全てのノードのデータ一致性確認を受信していなければ、或いは、合意したノード(即ち、ブロックチェーンシステムにおける最新のブロックのハッシュ値が一致するもの)が他の全てのノードのデータ一致性確認の放送メッセージを受信していなければ、クライアントは、PBFTアルゴリズムに切り替えるように全てのノードに通知する。
また、いずれのノードが他の全てのノードのデータ一致性確認の放送メッセージを受信していなければ、PBFTアルゴリズム状態に自動的に入ると共に、PBFTアルゴリズムに切り替える旨の通知を放送する。
ノードがf+1個以上の新アルゴリズム放送メッセージを受信した後(fは、PBFTアルゴリズムに基づいてブロックチェーンシステムにおいて許容されるエラーノードの最大値である)、新アルゴリズム(PBFT)中のマスターノードの投票を開始し、ビューの変更(view change)とも呼ばれ、完成した後、新しいPBFTアルゴリズムの合意形成段階に入る。
図13を参照すると、図13は、本発明の実施形態に提供されるブロックチェーンシステムがT−RAFTアルゴリズムによる合意形成からPBFTアルゴリズムによる合意形成に切り替える1つの任意的なフロー模式図であり、このメッセージフロー模式図において、仮にノード4は障害が発生したものであり、ノード1、2及び3は、クライアントからアルゴリズム切替通知を受信してPBFTアルゴリズムへの切替準備段階にあるとすると、それぞれデータ要求確認メッセージを放送し、メッセージに、自分の最新の合意形成したブロックのハッシュ値が付いており、ノード4は障害が発生したものであるため、ノード1、2、3はタイムアウト時間内にノード4の放送したデータ一致性確認(一致性応答)を受信できないので、データ一致性確認をクライアントへ送信することなく、ノード1、2、3及びクライアントはタイムアウトした後、それぞれ、PBFTアルゴリズムに切り替える旨の通知を放送し、ノード1、2、3はいずれもアルゴリズム切替通知を受信し、アルゴリズム切替通知がf+1よりも大きく、f+1個のアルゴリズム切替通知を真っ先に受信したノードは、まず最初にビューの変更フローを開始し、ビューの変更が完成した後、PBFTアルゴリズムによる合意形成に入る。
PBFTによる合意形成において、マスターノードは、データが完全に一致することが連続してM回(設定可能)発生したと統計していれば、T−RAFTの競合ノードに変換し、T−RAFTの投票プロセスをトリガーし、他のノードが投票要求を受信した後、連続した合意形成回数がM/2回を超えるか、或いは、一定の設定値Tを超えると統計していれば、競合ノードがマスターノードに変換することに同意し、全てのスレーブノードはそれぞれ競合ノードがマスターノードに変換することに同意した場合にのみ、T−RAFTアルゴリズムのコンセンサスモードに入り、各ノードの連続した合意形成回数は0へとクリアされる。競合ノードがマスターノードに変換することに同意しないスレーブノードが1つでもあれば、競合ノードはすぐに元の状態に戻り、即ち、PBFTアルゴリズムのマスターノードに変換し、継続してPBFTアルゴリズムを実行し、各ノードの合意形成統計回数は継続して累積し、M+Tになってから再びT−RAFT投票をトリガーし、成功しなければ、M+2T時刻で次回のトリガーを行い、マスターノードの投票が成功するまでこのように繰り返し、M+x*T時刻でトリガーし、ここで、xは回数である。
図14を参照すると、図14は、本発明の実施形態に提供されるブロックチェーンシステムがPBFTアルゴリズムのコンセンサスモードからT−RAFTアルゴリズムのコンセンサスモードに切り替える1つの任意的なフロー模式図であり、PBFTアルゴリズムのプロセスにおいて、マスターノード、即ちノード1は、データが連続して一致する(合意形成する)回数がM回を超えると統計した場合に、T−RAFTの競合ノード状態に変換し、その後、T−RAFTアルゴリズムの投票を開始し、ノード2、3及び4は、投票要求(request vote)メッセージを受信した後、連続してデータが一致する回数がM/2(又は、一定の値T)を超えると統計したか否かを判断し、YESであれば、競合ノードがマスターノードに変換することに同意する旨の切替確認を返信する。
競合ノードは、ノード2、3、4の切替確認を受信し、マスターノードに変換し、T−RAFTアルゴリズムの合意形成段階を開始する。T−RAFT投票プロセスにおいて、元のPBFTコンセンサスモードにおけるマスターノード(ノード1)がクライアントのメッセージを受信した後、これ以上シークエンシングメッセージ、例えば、PBFTアルゴリズムにおける事前準備(PRE-PREPARE)メッセージを送信しなくなり、投票が完了したら、T−RAFTにおいてメッセージをAppend Entries RPCに付加させてスレーブノードへ送信する。
さらに、実際の適用時の使用場面を結合して説明し、図15を参照すると、図15は、本発明の実施形態に提供される分散システムがコンソーシアムチェーンシステムに適用される1つの任意的なシーン模式図であり、コンソーシアムチェーンシステムはそれぞれの個人又はエンティティに開放されるものであり、複数のノードを含み、各ノードは第3者決済機構、及び銀行業務システム(クライアントとして)のためにアクセスを提供し、第3者決済機構、及び銀行業務システムのコミットした取引履歴を受け取り、ノードは、コミットした取引履歴に関して合意形成した後、この取引履歴をブロックチェーンの最新のブロックに記憶し、これにより、第3者決済機構及び契約を結んだ銀行はそれぞれの業務取引明細書に基づいて照合する。
ノードは、デフォルトに、T−RAFTコンセンサスモードを用いて取引履歴に対する合意を形成し、異常ノードが発生した場合にPBFTコンセンサスモードに切り替えて取引履歴に関しての合意を形成する。
ユーザの第3者決済端末に、ユーザの銀行におけるクレジットカード口座がボンディングされ、ユーザがベンダーとオフライン又はオンラインで取引する際に、第3者決済端末は、クレジットカードのアカウントの事前承認を予め得ることで、ユーザのクレジットカード口座からベンダーの口座を引き落としすることができ、取引履歴を形成する。
この取引の場合、第3者決済機構の業務システムは、分散システムにてアクセスするマスターノードへ取引履歴(例えば、受取人、支払人及び支払額を含み、第3者決済クライアントの電子署名が携帯されている)をコミットする。マスターノードは、受信された取引履歴の電子署名の検証に成功した後、取引履歴を同期して他のスレーブノードへ送信し(マスターノードの電子署名が携帯されている)、スレーブノードは、取引履歴の電子署名の検証に成功した後、第3者決済機構の業務システムへ結果を返信する(スレーブノードの電子署名、一意のフィールドが携帯され、マスターノードが新しいマスターノードとして投票された場合に、取引履歴の配列番号がさらに携帯されている)一方、同期が完了したことをマスターノードに通知する。マスターノードは、各スレーブノードの同期が完了したと確認した後、取引履歴をブロックチェーンの最新のブロックに記憶して各スレーブノードに通知し、スレーブノードが同様な操作を実行し、取引履歴の永続的な記憶を完成する。
上述した取引履歴に関する合意形成のプロセスにおいて、クライアントは、スレーブノードから返信された結果に基づいて、マスターノードが悪意のあるノードであるか、或いは、スレーブノードに障害が発生したと決定していれば、コンソーシアムチェーンシステムがPBFTコンセンサスモードに切り替えて取引履歴に関して合意形成するようにトリガーし、取引履歴が各ノードのブロックチェーンに順調に記憶されることを保証する。コンソーシアムチェーンシステムが第3者決済機構の業務システムが後でコミットした取引履歴の合意状況に応じて、よく合意を達成していれば(マスターノードと他のノードが連続してM回合意する)、T−RAFTコンセンサスモードに戻って合意形成効率を向上させることができる。
上述のように、本発明の実施形態は、以下の有益な効果を有する。
1)クライアントとノード間、ノード同士間では電子署名の方式により通信の信頼性を保証し、メッセージの偽造を回避し、分散システム内部の通信の信頼性を保証する。
2)スレーブノードは、マスターノードから送信されたメッセージを受信した場合に、結果を直接クライアントへ返信し、結果に、例えば一意のフィールド、メッセージ配列番号及び電子署名等の必要な情報が携帯され、このように、クライアントは、直接スレーブノードから返信された結果に基づいてスレーブノードの合意状況を判定でき、異常ノードを容易に検出できる。
3)異常ノードを検出した場合に、デフォルトに利用される合意形成効率の高い第1のコンセンサスモードからフォールトトレランス性能のより優れた第2のコンセンサスモードに切り替えることができ、分散システムは異常が発生した時でも順調に合意形成できることを確保する。
4)第2のコンセンサスモードにおいてよく合意を達成していれば(例えば、合意形成回数に基づいて判断する)、再び第1のコンセンサスモードに切り替え、このような適応型コンセンサスモードの切替は、合意形成効率とフォールトトレランス性能をうまく両立させている。分散システムの運転するネットワーク状態が良好であるほとんどの時間内に、合意形成効率が高いという技術効果を実現し、ノードに障害が発生し、或いはビザンチンフォールトトレランスノードがある場合に、分散システムの業務機能を正常に処理できることを保証する。
上述した方法実施形態を実現するステップの全部又は一部は、プログラムが関連するハードウェアを命令して完成させることができ、上述したプログラムは、コンピュータ読み取り可能な記憶媒体に記憶されることができ、このプログラムは、実行される際に、上述した方法実施形態を含むステップを実行する、と当業者が理解することができる。上述した記憶媒体は、モバイル記憶通信状態処理装置、ランダムアクセスメモリ(RAM、Random Access Memory)、リードオンリーメモリ(ROM、Read-Only Memory)、磁気ディスク又は光ディスク等、様々なプログラムのコードを記憶可能な媒体を含む。
或いは、本発明の上記集積したユニットは、ソフトウェア機能モジュールの形で実現されながら独立した製品として販売または使用される場合、コンピュータ読み取り可能な記憶媒体に記憶されることができる。このように理解すれば、本発明の実施形態の技術的構成は、本質的には、従来技術に貢献する部分、或いは、該技術的構成の全部又は一部をソフトウェア製品の形で表現でき、このコンピュータソフトウェア製品は、コンピュータデバイス(パソコン、サーバまたはネットワークデバイス等であってもよい)に本開示の各実施形態に記載の方法の全部又は一部を実行させるための若干の命令を含む記憶媒体に記憶される。上記記憶媒体は、モバイル記憶通信状態処理装置、RAM、ROM、磁気ディスク又は光ディスク等、様々なプログラムのコードを記憶可能な媒体を含む。
以上は、あくまでも本発明の具体的な実施形態であり、本発明の保護範囲はこれに限定されず、当業者が本発明に開示された技術範囲内において容易に想到し得る変更又は置き換えは、いずれも本発明の保護範囲内に含まれるべきである。それゆえ、特許請求の範囲の内容に基づいて本発明の保護範囲が定められるべきである。
200 ノード
210 プロセッサ
220 ネットワークインターフェース
230 記憶媒体
240 入出力インターフェース
250 ミドルウェア
260 オペレーティングシステム
270 コンセンサスメカニズム
2701 投票ユニット
2702 マスターノードユニット
2703 スレーブノードユニット
2704 切替ユニット
280 電子マネーウォレット
290 スマートコントラクト
300 クライアント
310 プロセッサ
320 ネットワークインターフェース
330 記憶媒体
340 入出力インターフェース
350 ミドルウェア
360 オペレーティングシステム
370 コンセンサス
3701 通信ユニット
3702 検出ユニット
3703 切替ユニット
380 管理ノード
390 配置されるスマートコントラクト
本発明の実施形態に提供される分散システム100がブロックチェーンシステムに適用される1つの任意的な構造模式図である。 本発明の実施形態に提供されるブロック構造の1つの任意的な模式図である。 本発明の実施形態に提供されるノード200の1つの任意的なソフトウェア・ハードウェア構造模式図である。 本発明の実施形態に提供されるクライアント300の1つの任意的なソフトウェア・ハードウェア構造模式図である。 本発明の実施形態に提供される第1のコンセンサスモードにおいて各ノードが投票操作を実行することでマスターノード及びスレーブノードを決定する1つの任意的な模式図である。 本発明の実施形態に提供される分散システムのノードが第1のコンセンサスモードにおいて合意形成し、障害ノード及び悪意のあるノードを検出する1つの任意的なフロー模式図である。 本発明の実施形態に提供される分散システムが第1のコンセンサスモードと第2のコンセンサスモード間を切り替える1つの任意的なフロー模式図である。 本発明の実施形態に提供される分散システムが第1のコンセンサスモードと第2のモード間を切り替える1つの任意的なフロー模式図である。 発明の実施形態に提供されるブロックチェーンシステムがRAFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図である。 発明の実施形態に提供されるブロックチェーンシステムがPBFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図である。 本発明の実施形態に提供される自己適応型コンセンサスアルゴリズムを実現する運転状態図である。 本発明の実施形態に提供されるT−RAFTアルゴリズムによる合意形成の実現模式図である。 本発明の実施形態に提供されるPBFTアルゴリズムへの切替準備段階においてT−RAFTアルゴリズムに戻る1つの任意的なフロー模式図である。 本発明の実施形態に提供されるブロックチェーンシステムがT−RAFTアルゴリズムによる合意形成からPBFTアルゴリズムによる合意形成に切り替える1つの任意的なフロー模式図である。 本発明の実施形態に提供されるブロックチェーンシステムがPBFTアルゴリズムのコンセンサスモードからT−RAFTアルゴリズムのコンセンサスモードに切り替える1つの任意的なフロー模式図である。 本発明の実施形態に提供される分散システムがコンソーシアムチェーンシステムに適用される1つの任意的なシーン模式図である。
4)コンセンサスモードの切替:コンセンサスモードの適応とも呼ばれ、分散ネットワークに使用されるコンセンサスアルゴリズムは、ネットワーク環境が良好である場合に、合意形成効率が高くて異常ノード(例えば、ビザンチン問題のあるノード)を検出できるアルゴリズムを自動的に利用して、第1のコンセンサスモードを実現するが、悪意のあるノード又はノードが誤っていることが判明した場合に、ビザンチンフォールトトレランスの問題を解決できるアルゴリズムに自動的に切り替えて第2のコンセンサスモードを実現する。
投票ユニット2701:第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、ノード200及び分散システムにおける他のノードが投票操作を実行することで、マスターノードの状態又はスレーブノードの状態にされるように構成される。
記憶媒体330は、フラッシュメモリ、ハードディスク、光ディスク等の不揮発性記憶媒体を用いて実現されることができれば、DDRを用いて実現されることもでき、上述したメッセージ処理方法を実行するための実行可能な命令を記憶している。
分散システムの動作時間は、連続するコンセンサス周期に分けられ、ここで、任期(Term)とも呼ばれ、各任期は、任意の時間長であってもよく、任期は、連続する整数で番号を付けられる。各任期で、まず最初にマスターノード投票を行い、投票段階において、複数の競合ノードがマスターノードとなるように競合し、あるノードがマスターノードになれば、他の競合ノードがスレーブノードに変換し、マスターノードとなったノードは、この任期内にずっとマスターノードを担い、このマスターノードに障害が生じたら、他のノードは新しい任期内に投票を行う。
任意の通信を行う双方はそれぞれ電子署名の方式を利用し、即ち、送信側はメッセージを送信する際にメッセージの電子署名を携帯させ、例えば、送信側の非対称暗号化アルゴリズムの秘密鍵を用いてメッセージのダイジェストを暗号化し、送信側の電子署名を形成し、受信側は、電子署名を検証することでメッセージの信頼性を保証し、即ち、メッセージの署名について、非対称暗号化アルゴリズムの公開鍵(受信側及び送信側が同じ非対称暗号化アルゴリズムを用いることを保証すれば、受信側は公開鍵を予め取得する)を用いて復号し、復号して得たダイジェストとメッセージから抽出されたダイジェストとを照合し、一致していれば、電子署名の検証が通過し、送信側から送信されたメッセージが信頼できることが分かる。
例えば、分散システムが第2のコンセンサスメカニズムにあり、仮にノード1をマスターノードとし、ノード2〜ノードNをスレーブノードとすると、各ノードがクライアントからのメッセージに関して合意形成することをカウントし、ノード1にとって、ノード1とノード2〜ノードNは、最近クライアントから送られたM個(マスターノードの合意形成回数の閾値)のメッセージのそれぞれに関して合意を達成していれば、各ノード間でよく合意を達成したことが示され、ノード1は第1のコンセンサスモードに切り替える旨の通知をノード2〜ノードNへ送信し、ノード2〜ノードNはノード1へ切替確認を送信し、ノード1が第1のコンセンサスモードにおいてもマスターノードであることを承認して、ノード2〜ノードNが継続してスレーブノードであり、ノード2〜ノードNにおいて悪意のあるノードが生じても、クライアントからのメッセージを偽造できず、ノードの合意形成効率を確保する。
分散システムが第2のコンセンサスモードにあるときに、スレーブノードは、第2のコンセンサスモードにおいてクライアントからのメッセージに関して他のノード(マスターノード及び他のスレーブノードを含む)と合意形成する回数を統計し、合意形成回数がスレーブノードの合意形成回数の閾値を超えていれば(マスターノードの合意形成回数の閾値以下であってもよく、例えば、M/2であることができる)、マスターノードが第1のコンセンサスモードにおいて継続してマスターノードであることに同意する旨の通知をマスターノードへ送信し、第2のコンセンサスモードにおけるスレーブノードは、第1のコンセンサスモードに切り替えるときに継続してスレーブノードであり、これにより、第1のコンセンサスモードに切り替える投票操作を完成し、継続して第1のコンセンサスモードにおいてクライアントからのメッセージに関して合意形成する。このように、第1のコンセンサスモードにおいて悪意のあるノードがマスターノードになることを回避することができ、合意形成効率を確保する。
図8を参照すると、図8は、発明の実施形態に提供されるブロックチェーンシステムがRAFTアルゴリズムを利用して合意形成する1つの任意的なフロー模式図であり、クライアントがメッセージをマスターノード(leaderノード)へ送信した後、マスターノードは、受信されたメッセージを並び替え、並び替える順に従ってスレーブノード(followerノード)に配布し、他のfollowerは、leaderノードが並び替えた順に従ってメッセージをログに記憶し、leaderノードへRPC結果(result)を返信し、その後、leaderノードは、ログにおけるメッセージをローカルの磁気ディスクに記憶してから、各スレーブノードへコミット(Commit)を送信し、各スレーブノードは、ログにおけるメッセージをスレーブノードのローカル磁気ディスクに記憶すれば、メッセージの一致性を同期させることを完成し、効率が高いが、ビザンチンノード問題を解決できない。
4)第2のコンセンサスモードにおいてよく合意を達成していれば(例えば、合意形成回数に基づいて判断する)、再び第1のコンセンサスモードに切り替え、このような適応型コンセンサスモードの切替は、合意形成効率とフォールトトレランス性能をうまく両立させている。分散システムの運転するネットワーク状態が良好であるほとんどの時間内に、合意形成効率が高いという技術効果を実現し、ノードに障害が発生し、或いはビザンチンノードがある場合に、分散システムの業務機能を正常に処理できることを保証する。

Claims (35)

  1. 分散システムであって、
    クライアントと複数のノードとを備え、
    前記ノードは、第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成され、
    前記ノードは、マスターノードの状態にある場合に、前記クライアントから送信されたメッセージの電子署名を検証し、前記メッセージを前記スレーブノードへ送信するように構成され、
    前記ノードは、マスターノードの状態にある場合に、所定数を超えた前記スレーブノードの受信確認通知を受信し、前記受信確認通知の電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成され、
    前記ノードは、さらに、スレーブノードの状態にある場合に、前記マスターノードから送信された前記メッセージを受信したときに前記クライアントへ結果を返信し、前記マスターノードから受信したメッセージの電子署名を検証して、前記マスターノードへ受信確認通知を送信するように構成され、
    前記ノードは、スレーブノードの状態にある場合に、前記マスターノードから受信したメッセージ記憶通知の電子署名を検証して、前記マスターノードから受信したメッセージを永続的に記憶するように構成され、
    前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される、
    分散システム。
  2. 前記クライアントは、さらに、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージにおける一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定し、結果を返信していないスレーブノードを障害ノードとして決定するように構成される、
    請求項1に記載の分散システム。
  3. 前記クライアントは、さらに、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、前記マスターノードが悪意のあるノードであると判定するように構成される、
    請求項1に記載の分散システム。
  4. 前記クライアントは、さらに、前記マスターノードが悪意のあるノードであると決定し、或いは、前記スレーブノードに障害ノードが存在すると決定した場合に、前記分散システムにおけるノードが第2のコンセンサスモードに切り替えるようにトリガーする、
    請求項1に記載の分散システム。
  5. 前記ノードは、さらに、前記第2のコンセンサスモードに切り替える準備段階にある場合に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、対応するノードの電子署名が携帯されている一致性確認を前記クライアントへ送信するように構成され、
    前記クライアントは、さらに、所定の時間内に全ての前記ノードの一致性確認を受信した場合に、前記分散システムにおけるノードが前記第1のコンセンサスモードに戻るように通知し、前記所定の時間内には全ての前記ノードの一致性確認を受信していない場合に、前記分散システムにおけるノードが継続して前記第2のコンセンサスモードに切り替えるように通知する、
    請求項4に記載の分散システム。
  6. 前記ノードは、さらに、前記第2のコンセンサスモードに切り替える準備段階にある場合に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、メッセージの送信ノードへ、対応するノードの電子署名が携帯されているデータ確認を送信するように構成され、
    前記クライアントは、さらに、所定の時間内には合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、前記分散システムにおけるノードが継続して前記第2のコンセンサスモードに切り替えるようにトリガーする、
    請求項4に記載の分散システム。
  7. 前記ノードは、さらに、マスターノードの状態にあるとともに、前記第2のコンセンサスモードにおいて統計した回数であって、受信したメッセージに関して前記スレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、前記スレーブノードとともに前記第1のコンセンサスモードに切り替えに関して合意形成するように構成される、
    請求項4に記載の分散システム。
  8. 前記ノードは、さらに、マスターノードの状態にあるとともに、統計した回数がマスターノードの合意形成回数の閾値を超えた場合に、前記第1のコンセンサスモードに切り替える旨の通知を前記スレーブノードへ送信し、全ての前記スレーブノードから送信された切替確認を受信した場合に、前記スレーブノードと同期して前記第1のコンセンサスモードに切り替えるように構成される、
    請求項7に記載の分散システム。
  9. 前記ノードは、さらに、スレーブノードの状態にあり、前記第1のコンセンサスモードに切り替える旨の通知を受信し、かつ、受信したメッセージに関して合意形成した回数がスレーブノードの合意形成回数の閾値を超えたと統計した場合に、前記マスターノードへ切替確認を送信するように構成される、
    請求項8に記載の分散システム。
  10. 前記ノードは、さらに、前記マスターノードの心拍情報を受信していない場合に、或いは、前記マスターノードが悪意のあるノードである場合に、投票操作を再実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される、
    請求項1に記載の分散システム。
  11. 前記ノードは、さらに、新しいコンセンサス周期が到来し、かついずれのノードから送信された心拍情報も受信していない場合に、前記分散システムにおけるノードへ投票要求を送信し、所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換して前記分散システムにおけるノードへ心拍情報を定期的に送信するように構成され、
    投票確認は、前記分散システムにおけるノードが送信され、かつ送信される前には前記投票要求に携帯された電子署名は検証され、
    前記ノードは、さらに、新しいコンセンサス周期が到来し、かつ前記分散システムにおけるノードから送信された心拍情報を受信した場合に、スレーブノードの状態に変換するように構成される、
    請求項1に記載の分散システム。
  12. メッセージ処理方法であって、
    第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、分散システムにおけるノードが投票操作を実行し、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されることと、
    前記ノードがマスターノードの状態にある場合に、前記ノードは、
    クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信する操作と、
    所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信する操作とを実行することと、を含み、
    前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、
    メッセージ処理方法。
  13. 前記ノードがスレーブノードの状態にある場合に、前記ノードは、
    前記マスターノードから送信されたメッセージを受信し、前記クライアントへ結果を返信して、受信されたメッセージの電子署名を検証した後に前記マスターノードへ受信確認通知を送信する操作と、
    受信されたメッセージ記憶通知の電子署名を検証した後、受信されたメッセージを永続的に記憶する操作とを実行すること、をさらに含む、
    請求項12に記載のメッセージ処理方法。
  14. 前記ノードがスレーブノードの状態にある場合に、前記スレーブノードが前記クライアントへ返信した結果に、前記メッセージの一意のフィールド、前記スレーブノードの電子署名の情報が携帯され、
    前記結果は、前記クライアントが携帯された電子署名を検証し、前記結果に含まれる一意のフィールドと送信されたメッセージの一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定するために用いられる、
    請求項12に記載のメッセージ処理方法。
  15. 前記ノードがスレーブノードの状態にある場合に、前記スレーブノードの返信した結果に、前記スレーブノードの受信したメッセージの配列番号が携帯され、
    前記結果は、前記クライアントが携帯された配列番号と送信されたメッセージの配列番号とを比較し、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、前記マスターノードが悪意のあるノードであると決定するために用いられる、
    請求項12に記載のメッセージ処理方法。
  16. 前記クライアントは、前記マスターノードが悪意のあるノードであると決定し、或いは、前記スレーブノードに障害ノードが存在すると決定した場合に、前記ノードは、前記クライアントのトリガーに応えて第2のコンセンサスモードに切り替えること、をさらに含む、
    請求項12に記載のメッセージ処理方法。
  17. 前記ノードが前記第2のコンセンサスモードに切り替える準備段階にある場合に、前記ノードは、
    前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、前記クライアントへ、対応するノードの電子署名が携帯されている一致性確認を送信する操作と、
    前記クライアントが所定の時間内に全ての前記ノードの一致性確認を受信した場合に、前記ノードは、前記クライアントの通知に応えて、継続して前記第1のコンセンサスモードに切り替える操作と、
    前記クライアントが所定の時間内には全ての前記ノードの一致性確認を受信していない場合に、前記ノードは、前記クライアントの通知に応えて、継続して前記第2のコンセンサスモードに切り替える操作とを実行すること、をさらに含む、
    請求項16に記載のメッセージ処理方法。
  18. 前記ノードが前記第2のコンセンサスモードに切り替える準備段階にある場合に、前記ノードは、
    前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とを比較し、一致すると確認した場合に、メッセージの送信ノードへ、対応するノードの電子署名が携帯されているデータ確認を送信する操作と、
    所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、前記所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、前記ノードは、前記クライアントのトリガーに応えて、継続して前記第2のコンセンサスモードに切り替える操作とを実行すること、をさらに含む、
    請求項16に記載のメッセージ処理方法。
  19. 前記ノードがマスターノードの状態にあり、かつ前記第2のコンセンサスモードにおいて統計した回数であって、受信したメッセージに関して前記スレーブノードと合意形成したカウント数である回数がマスターノードの合意形成回数の閾値を超えた場合に、前記スレーブノードとともに前記第1のコンセンサスモードに切り替えること、をさらに含む、
    請求項16に記載のメッセージ処理方法。
  20. 前記スレーブノードとともに前記第1のコンセンサスモードに切り替えることは、
    前記マスターノードが前記第1のコンセンサスモードに切り替える旨の通知を前記スレーブノードへ送信し、全ての前記スレーブノードから送信された切替確認を受信した場合に、前記スレーブノードと同期して前記第1のコンセンサスモードに切り替えることを含む、
    請求項19に記載のメッセージ処理方法。
  21. 前記ノードがスレーブノードの状態にある場合に、
    前記第1のコンセンサスモードに切り替える旨の通知を受信したときに、受信したメッセージに関して合意形成した回数を統計し、統計した回数がスレーブノードの合意形成回数の閾値を超えた場合に、前記マスターノードへ切替確認を送信する操作を実行すること、をさらに含む、
    請求項20に記載のメッセージ処理方法。
  22. 前記スレーブノードが前記マスターノードの心拍情報を受信していない場合に、或いは、前記マスターノードが悪意のあるノードである場合に、前記分散システムにおけるノードが投票操作を再実行することで、マスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されること、をさらに含む、
    請求項12に記載のメッセージ処理方法。
  23. 新しいコンセンサス周期が到来し、かつ心拍情報を受信していない場合に、前記ノードは、前記分散システムにおけるノードへ、前記ノードの電子署名が携帯されている投票要求を送信し、
    所定数のノードから返信された投票確認を受信した場合に、マスターノードの状態に変換し、前記ノードは前記分散システムにおけるノードへ心拍情報を定期的に送信し、
    前記投票確認は、前記分散システムにおけるノードが前記投票要求に携帯された電子署名を検証する後に送信され、
    新しいコンセンサス周期が到来し、かつ前記分散システムにおけるノードから送信された心拍情報を受信した場合に、スレーブノードの状態に変換する、
    請求項12に記載のメッセージ処理方法。
  24. メッセージ処理方法であって、
    クライアントは、分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信することと、
    前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは前記マスターノードの電子署名が携帯されて、前記分散システムにおけるスレーブノードへ送信されることと、
    前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果を受信することと、
    前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することと、を含む、
    メッセージ処理方法。
  25. 前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することは、
    前記クライアントは、受信された結果の電子署名を検証した後、受信された結果に含まれる一意のフィールドと送信されたメッセージにおける一意のフィールドとを比較し、一致しない一意のフィールドが対応するスレーブノードをエラーノードとして決定するとともに、対応する結果を返信していないスレーブノードを障害ノードとして決定することを含む、
    請求項24に記載のメッセージ処理方法。
  26. 前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することは、
    前記クライアントは、受信された結果に携帯された配列番号と送信されたメッセージの配列番号との比較により、一致しない配列番号を送信したスレーブノードの数が一致しない数の閾値を超えた場合に、前記マスターノードが悪意のあるノードであると判定することを含む、
    請求項24に記載のメッセージ処理方法。
  27. 前記クライアントは、前記マスターノードが悪意のあるノードであると決定した場合に、或いは、前記クライアントは、前記スレーブノードに障害ノードが存在すると決定した場合に、前記分散システムのノードが第2のコンセンサスモードに切り替えるようにトリガーすること、をさらに含む、
    請求項24に記載のメッセージ処理方法。
  28. 前記クライアントは、所定の時間内に全ての前記ノードの一致性確認を受信した場合に、全ての前記ノードが第1のコンセンサスモードに戻るように通知することと、
    前記クライアントは、所定の時間内には全ての前記ノードの一致性確認を受信していない場合に、全ての前記ノードが継続して前記第2のコンセンサスモードに切り替えるように通知することと、をさらに含み、
    前記一致性確認は、前記ノードの電子署名を携帯しており、前記ノードが前記第2のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ、送信される前に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおけるノードに永続的に記憶されたメッセージのハッシュ値とが一致すると確認する、
    請求項27に記載のメッセージ処理方法。
  29. 所定の時間内に合意したノードが合意していないノードのデータ確認を受信していない場合に、或いは、所定の時間内に分散システムにおけるノードがデータ確認を受信していない場合に、前記クライアントは、前記分散システムにおけるノードが継続して前記第2のコンセンサスモードに切り替えるようにトリガーすること、をさらに含み、
    前記データ確認は、対応するノードの電子署名を携帯しており、前記ノードが前記第2のコンセンサスモードに切り替える準備段階にあるときに送信され、かつ、送信される前に、前記ノードに永続的に記憶されたメッセージのハッシュ値と、前記分散システムにおいて永続的に記憶されたメッセージのハッシュ値とが一致すると確認する、
    請求項27に記載のメッセージ処理方法。
  30. 分散システムにおけるノードであって、
    第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、投票操作を実行することで、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されるように構成される投票ユニットと、
    前記ノードがマスターノードの状態にある場合に、クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信し、そして、
    所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信するように構成されるマスターノードユニットと、を備え、
    前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、
    ノード。
  31. 分散システムにおけるノードであって、1つ又は複数のプロセッサと、メモリと、1つ以上のプログラムとを備え、前記1つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれ一群の命令に対応する1つ以上のユニットを含むことができ、前記1つ又は複数のプロセッサは、命令を実行する際にメッセージ処理方法を実現するように構成され、前記メッセージ処理方法は、
    第1のコンセンサスモードにおいて新しいコンセンサス周期が到来した場合に、分散システムにおけるノードが投票操作を実行し、投票操作によりマスターノードの状態にあるかそれともスレーブノードの状態にあるかが決定されることと、
    前記ノードがマスターノードの状態にある場合に、前記ノードは、
    クライアントのメッセージを受信し、前記メッセージの電子署名を検証して、前記メッセージを前記スレーブノードへ送信する操作と、
    所定数を超えた前記スレーブノードの受信確認通知を受信し、前記確認受信メッセージの電子署名を検証した後に前記メッセージを永続的に記憶して、前記スレーブノードへメッセージ記憶通知を送信する操作とを実行することと、を含み、
    前記スレーブノードが前記メッセージを受信したときに返信した結果は、前記クライアントが前記分散システムにおける異常ノードを決定するために用いられる、
    ノード。
  32. 分散システムにおけるクライアントであって、
    分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信し、
    前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を携帯されて、前記分散システムにおけるスレーブノードへ送信され、
    前記スレーブノードは、前記メッセージを受信したときに返信した結果を受信する
    ように構成される通信ユニットと、
    前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定するように構成される検出ユニットと、を備える、
    クライアント。
  33. 分散システムにおけるクライアントであって、1つ又は複数のプロセッサと、メモリと、1つ以上のプログラムとを備え、前記1つ以上のプログラムがメモリに記憶され、前記プログラムは、それぞれが一群の命令に対応する1つ以上のユニットを含むことができ、前記1つ又は複数のプロセッサは、命令を実行する際にメッセージ処理方法を実現するように構成され、前記メッセージ処理方法は、
    クライアントは、分散システムのノードのうちのマスターノードへ、前記クライアントの電子署名が携帯されているメッセージを送信することと、
    前記電子署名は、前記マスターノードが検証するのに用いられ、受信されたメッセージは、前記マスターノードの電子署名を携帯されて、前記分散システムにおけるスレーブノードへ送信することと、
    前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果を受信することと、
    前記クライアントは、前記スレーブノードが前記メッセージを受信したときに返信した結果に基づいて、前記分散システムにおける異常ノードを決定することと、を含む、
    クライアント。
  34. プロセッサに、実行可能なプログラムを実行する際に、請求項12乃至23のいずれか一項に記載のメッセージ処理方法を実現させるための前記実行可能なプログラムが記憶されている記憶媒体。
  35. プロセッサに、実行可能なプログラムを実行する際に、請求項24乃至29のいずれか一項に記載のメッセージ処理方法を実現させるための前記実行可能なプログラムが記憶されている記憶媒体。
JP2019531777A 2017-03-30 2018-03-26 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体 Active JP6883106B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201710203499.X 2017-03-30
CN201710203499.XA CN106789095B (zh) 2017-03-30 2017-03-30 分布式系统及消息处理方法
PCT/CN2018/080574 WO2018177264A1 (zh) 2017-03-30 2018-03-26 分布式系统、消息处理方法、节点、客户端及存储介质

Publications (3)

Publication Number Publication Date
JP2020512708A true JP2020512708A (ja) 2020-04-23
JP2020512708A5 JP2020512708A5 (ja) 2021-01-14
JP6883106B2 JP6883106B2 (ja) 2021-06-09

Family

ID=58965529

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019531777A Active JP6883106B2 (ja) 2017-03-30 2018-03-26 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体

Country Status (7)

Country Link
US (2) US11237896B2 (ja)
EP (1) EP3605947B1 (ja)
JP (1) JP6883106B2 (ja)
KR (1) KR102248454B1 (ja)
CN (3) CN106789095B (ja)
TW (1) TWI662435B (ja)
WO (1) WO2018177264A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021520574A (ja) * 2019-11-06 2021-08-19 アリペイ (ハンジョウ) インフォメーション テクノロジー カンパニー リミテッドAlipay (Hangzhou) Information Technology Co., Ltd. 誤り訂正符号に基づく共有されたブロックチェーンデータの記憶のデータセキュリティ
JP2023509889A (ja) * 2020-05-21 2023-03-10 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム

Families Citing this family (144)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9529923B1 (en) 2015-08-28 2016-12-27 Swirlds, Inc. Methods and apparatus for a distributed database within a network
US9390154B1 (en) 2015-08-28 2016-07-12 Swirlds, Inc. Methods and apparatus for a distributed database within a network
US10747753B2 (en) 2015-08-28 2020-08-18 Swirlds, Inc. Methods and apparatus for a distributed database within a network
SG11201903278YA (en) 2016-11-10 2019-05-30 Swirlds Inc Methods and apparatus for a distributed database including anonymous entries
KR102433285B1 (ko) 2016-12-19 2022-08-16 스월즈, 인크. 이벤트들의 삭제를 가능하게 하는 분산 데이터베이스를 위한 방법 및 장치
CN106789095B (zh) 2017-03-30 2020-12-08 腾讯科技(深圳)有限公司 分布式系统及消息处理方法
CN108063787A (zh) * 2017-06-26 2018-05-22 杭州沃趣科技股份有限公司 基于分布式一致性状态机实现双活架构的方法
JP6745004B1 (ja) * 2017-07-11 2020-08-19 スワールズ,インコーポレイテッド ネットワーク内に分散データベースを効率的に実装するための方法及び機器
CN109426952B (zh) * 2017-08-22 2021-06-01 汇链丰(北京)科技有限公司 一种区块链架构
CN108023729B (zh) * 2017-10-13 2020-06-23 中国银联股份有限公司 区块链网络及其交易方法
CN107819749A (zh) * 2017-10-26 2018-03-20 平安科技(深圳)有限公司 基于以太坊的区块链系统和交易数据处理方法
KR102452425B1 (ko) 2017-11-01 2022-10-06 스월즈, 인크. 고속 카피가능 데이터베이스를 효율적으로 구현하기 위한 방법들 및 장치
CN109819003A (zh) * 2017-11-22 2019-05-28 南京理工大学 一种区块链的分层共识方法和系统
CN108009445B (zh) * 2017-11-30 2021-05-11 成都蓝海贝信息技术有限公司 一种半中心化的可信数据管理系统
CN108182581B (zh) * 2017-12-29 2020-08-11 北京欧链科技有限公司 一种区块链的记账方法及装置
CN108876359A (zh) * 2018-01-03 2018-11-23 上海指旺信息科技有限公司 基于区块链的电子钱包平台
US11838426B2 (en) * 2018-01-16 2023-12-05 Nchain Licensing Ag Computer implemented method and system for obtaining digitally signed data
CN108269190A (zh) * 2018-01-17 2018-07-10 深圳四方精创资讯股份有限公司 基于跨链中继平台的跨链方法及其系统
CN108347350B (zh) * 2018-01-25 2022-04-15 中国银联股份有限公司 一种通信方法及装置
CN109842606B (zh) * 2018-02-24 2020-08-18 中国科学院计算技术研究所 基于一致性哈希算法的区块链共识算法和系统
CN110489485B (zh) * 2018-04-28 2023-05-30 腾讯科技(深圳)有限公司 联盟区块链网络及在其中存储产品数据的方法和存储介质
US11095714B2 (en) 2018-05-01 2021-08-17 YugaByte Inc Orchestration of data services in multiple cloud infrastructures
CN108848056B (zh) * 2018-05-03 2021-05-04 南京理工大学 基于验证的区块链共识方法
CN108737175B (zh) * 2018-05-19 2021-04-23 上海分布信息科技有限公司 一种节点管理方法及其实现系统
WO2019226099A1 (en) * 2018-05-23 2019-11-28 Haj Enterprise Ab A system and a method for achieving consensus between multiple parties on an event
CN108768787B (zh) * 2018-06-25 2020-10-02 中国联合网络通信集团有限公司 一种区块链节点激励方法及装置
CN109003175B (zh) * 2018-07-06 2021-08-10 国网汇通金财(北京)信息科技有限公司 一种基于区块链的对账方法及系统
CN110740113B (zh) 2018-07-20 2021-10-29 富士通株式会社 通过多个主体协作进行信息处理的方法和装置
CN109126098A (zh) * 2018-07-26 2019-01-04 深圳市梵高夫科技有限公司 基于区块链的竞赛仲裁方法、系统、核心节点及存储介质
CN110784331B (zh) * 2018-07-30 2022-05-13 华为技术有限公司 一种共识流程恢复方法及相关节点
CN108881488B (zh) * 2018-08-01 2020-12-22 夸克链科技(深圳)有限公司 一种基于分域的区块链交易处理方法及网络
WO2020033048A1 (en) * 2018-08-09 2020-02-13 Hrl Laboratories, Llc System and method for consensus ordering of broadcast messages
US10848375B2 (en) 2018-08-13 2020-11-24 At&T Intellectual Property I, L.P. Network-assisted raft consensus protocol
CN109218079B (zh) * 2018-08-16 2021-09-10 北京京东尚科信息技术有限公司 一种区块链网络、部署方法及存储介质
CN109257334B (zh) * 2018-08-21 2021-04-09 广州杰赛科技股份有限公司 一种基于区块链的数据上链系统、方法及存储介质
CN109347906B (zh) * 2018-08-30 2021-04-20 腾讯科技(深圳)有限公司 一种数据传输方法、装置、与服务器
CN109194646B (zh) * 2018-08-30 2021-05-25 东北大学 一种基于区块链的安全认证数据存取方法
CN108989465B (zh) * 2018-08-30 2021-03-12 交叉信息核心技术研究院(西安)有限公司 共识方法、服务器、存储介质及分布式系统
CN109213828B (zh) * 2018-09-18 2021-08-20 百度在线网络技术(北京)有限公司 区块生成方法、装置、设备及存储介质
CN109241362B (zh) * 2018-09-18 2020-12-01 百度在线网络技术(北京)有限公司 区块生成方法、装置、设备及存储介质
CN109344630B (zh) * 2018-09-18 2021-07-02 百度在线网络技术(北京)有限公司 区块生成方法、装置、设备和存储介质
CN109284630B (zh) * 2018-09-21 2020-12-08 深圳市九洲电器有限公司 文件编辑方法、装置、系统及可读存储介质
CN109544334B (zh) * 2018-10-22 2020-09-29 深圳市哈希树科技有限公司 一种网络可扩展性区块链实现方法
CN109408203B (zh) * 2018-11-01 2019-10-18 无锡华云数据技术服务有限公司 一种队列消息一致性的实现方法、装置、计算系统
CN109614405A (zh) * 2018-11-30 2019-04-12 无锡井通网络科技有限公司 用于区块链的网络实况系统
CN109451039B (zh) * 2018-12-07 2021-06-04 上海分布信息科技有限公司 一种网络信息传输处理方法
US20200394183A1 (en) * 2019-06-12 2020-12-17 Subramanya R. Jois System and method of executing, confirming and storing a transaction in a serverless decentralized node network
CN109727029A (zh) * 2018-12-18 2019-05-07 杭州茂财网络技术有限公司 一种联盟链共识方法和系统
CN109785131A (zh) * 2018-12-21 2019-05-21 昆明理工大学 一种基于区块链的电力交易方法
CN111352943A (zh) * 2018-12-24 2020-06-30 华为技术有限公司 实现数据一致性的方法和装置、服务器和终端
CN110022345B (zh) * 2018-12-28 2020-03-24 阿里巴巴集团控股有限公司 联盟链中的请求处理方法、系统、装置及设备
CN109587271B (zh) * 2018-12-29 2020-06-09 杭州复杂美科技有限公司 主链平行链架构系统及区块同步方法、设备和存储介质
CN109495516A (zh) * 2019-01-07 2019-03-19 国网江苏省电力有限公司无锡供电分公司 基于区块链的电力物联网终端接入方法
CN109857751A (zh) * 2019-01-23 2019-06-07 平安科技(深圳)有限公司 基于区块链的跨平台数据更新方法、装置和计算机设备
CN109831425B (zh) * 2019-01-25 2022-02-15 中国联合网络通信集团有限公司 区块链共识方法、装置、设备及计算机可读存储介质
CN109816021B (zh) * 2019-01-28 2021-07-13 网易(杭州)网络有限公司 智能合约处理方法及装置、系统、存储介质和电子设备
CN109828979A (zh) * 2019-01-31 2019-05-31 浙江小泰科技有限公司 一种数据一致性检测方法及系统
US11226910B2 (en) * 2019-03-04 2022-01-18 Qualcomm Incorporated Ticket based request flow control
CN110061856A (zh) * 2019-03-07 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的通信方法、装置及电子设备
ES2862428T3 (es) 2019-03-18 2021-10-07 Advanced New Technologies Co Ltd Recuperación de tiempo de inactividad de sistema de consenso
KR102170345B1 (ko) 2019-03-18 2020-10-28 알리바바 그룹 홀딩 리미티드 뷰 변경 프로토콜을 종료하기 위한 시스템 및 방법
AU2019203865B2 (en) 2019-03-18 2021-01-21 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US10938750B2 (en) 2019-03-18 2021-03-02 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
CA3057395A1 (en) 2019-03-18 2019-05-31 Alibaba Group Holding Limited System and method for ending view change protocol
CN109902074B (zh) * 2019-04-17 2021-02-09 江苏全链通信息科技有限公司 基于数据中心的日志存储方法和系统
JP6991427B2 (ja) * 2019-04-26 2022-01-12 株式会社シーズ 電子機器、情報処理システム
WO2020218478A1 (ja) * 2019-04-26 2020-10-29 株式会社シーズ 電子機器、情報処理システム
CN110096381B (zh) * 2019-05-10 2021-05-07 百度在线网络技术(北京)有限公司 远程过程调用的实现方法、装置、设备和介质
US11228446B2 (en) 2019-05-10 2022-01-18 Advanced New Technologies Co., Ltd. Blockchain-based reconciliation method and apparatus and electronic device
CN110263582A (zh) * 2019-05-10 2019-09-20 阿里巴巴集团控股有限公司 一种基于联盟链的对账方法、装置及电子设备
SG11202109729SA (en) 2019-05-22 2021-10-28 Swirlds Inc Methods and apparatus for implementing state proofs and ledger identifiers in a distributed database
US11611439B2 (en) * 2019-06-11 2023-03-21 Celo Foundation Tree structure for byzantine fault tolerance
CN112150141A (zh) * 2019-06-26 2020-12-29 京东数字科技控股有限公司 一种区块链共识方法、装置和系统
CN110380934B (zh) * 2019-07-23 2021-11-02 南京航空航天大学 一种分布式余度系统心跳检测方法
CN110445570B (zh) * 2019-07-25 2021-07-20 腾讯科技(深圳)有限公司 一种时间校准方法、装置及计算机存储介质
CN110417889B (zh) * 2019-07-30 2022-02-01 中国联合网络通信集团有限公司 一种基于ipfs的数据传输方法及装置
US20220337436A1 (en) * 2019-08-16 2022-10-20 Zeu Technologies, Inc. Method and System for a Decentralized Transactional Communication Protocol
CN110460536B (zh) * 2019-08-26 2022-11-29 中国工商银行股份有限公司 用于区块链的数据处理方法和装置、介质和电子设备
CN110730204B (zh) * 2019-09-05 2022-09-02 创新先进技术有限公司 区块链网络中删除节点的方法和区块链系统
CN110769028B (zh) * 2019-09-10 2022-04-15 陕西优米数据技术股份有限公司 基于区块链技术的图案授权共识系统及方法
CN110830260B (zh) * 2019-09-27 2021-09-24 电子科技大学 一种基于区块链的数字签名的时间戳生成方法
CN110766552B (zh) * 2019-09-28 2023-10-20 北京瑞卓喜投科技发展有限公司 基于区块链的业务处理方法及装置
CN110784461B (zh) * 2019-10-23 2020-05-12 北方工业大学 一种基于区块链的安全6LoWPAN通信方法及系统
CN110798308A (zh) * 2019-10-31 2020-02-14 支付宝(杭州)信息技术有限公司 一种区块链的签名方法和系统
KR102285882B1 (ko) * 2019-11-19 2021-08-05 한양대학교 산학협력단 가변 정족수 기반의 블록체인 합의 방법, 이를 이용하는 블록체인 노드 및 프로그램
CN111611316A (zh) * 2019-11-27 2020-09-01 朱培培 基于区块链的数据传输装置
CN110958253A (zh) * 2019-12-05 2020-04-03 全链通有限公司 基于区块链的电子投票方法、设备及存储介质
CN111147494B (zh) * 2019-12-27 2022-11-18 杭州趣链科技有限公司 一种面向区块链轻节点的多中心接入的管理方法和装置
CN111179063B (zh) * 2019-12-31 2023-06-23 中国银行股份有限公司 基于区块链的信用卡业务数据处理方法、系统及相关节点
CN111107103B (zh) * 2019-12-31 2022-04-15 南京可信区块链与算法经济研究院有限公司 一种联盟链的性能维持方法、系统及存储介质
CN111274317A (zh) * 2020-01-07 2020-06-12 书生星际(北京)科技有限公司 多节点数据同步的方法和装置,以及计算机设备
CN111277645B (zh) * 2020-01-16 2023-02-10 深圳市迅雷网络技术有限公司 主备节点热切换方法、区块链系统、区块链节点及介质
CN113291355B (zh) * 2020-02-24 2023-05-23 中国航天科工飞航技术研究院(中国航天海鹰机电技术研究院) 超高速列车牵引驱动设备通信方法及系统
CN111311414B (zh) * 2020-02-27 2023-12-08 杭州云象网络技术有限公司 一种基于一致性哈希算法的区块链多方共识方法
CN111416703A (zh) * 2020-03-16 2020-07-14 北京有链科技有限公司 一种区块链跨越式和跳跃式快速同步方法及系统
CN111431999B (zh) * 2020-03-23 2022-11-25 杭州小影创新科技股份有限公司 一种基于Paxos算法的云函数分布式系统
CN111464349A (zh) * 2020-03-30 2020-07-28 南京中诚区块链研究院有限公司 区块链Raft+PBFT的混合共识网络算法及系统
CN111464356B (zh) * 2020-04-01 2021-11-05 腾讯科技(深圳)有限公司 一种区块共识周期切换方法、装置及计算机设备
CN111510347B (zh) * 2020-04-08 2021-10-26 北京链化未来科技有限公司 一种提高区块链共识效率的方法
CN111431931A (zh) * 2020-04-12 2020-07-17 中信银行股份有限公司 节点共识方法及装置
CN111586110B (zh) * 2020-04-22 2021-03-19 广州锦行网络科技有限公司 一种raft在出现点对点故障时的优化处理方法
CN113301002B (zh) * 2020-04-24 2023-05-09 阿里巴巴集团控股有限公司 一种信息处理方法、装置、电子设备以及存储介质
CN111695994B (zh) * 2020-05-12 2023-12-26 成都芯域矩阵科技有限公司 一种基于信用评分的区块链共识方法及系统
CN111682942B (zh) * 2020-05-18 2022-06-10 哈尔滨工业大学 一种应用于许可链的二元加权拜占庭容错共识方法
CN111654415B (zh) * 2020-05-28 2021-09-10 腾讯科技(深圳)有限公司 基于区块链的信息处理方法、装置、设备及可读存储介质
CN111756823A (zh) * 2020-06-12 2020-10-09 山西警察学院 基于简化拜占庭容错算法的应用于公安系统的开放许可链
US11882222B2 (en) * 2020-07-23 2024-01-23 The Toronto-Dominion Bank Multidirectional synchronization of confidential data using distributed ledgers
CN111988321B (zh) * 2020-08-24 2022-02-11 桂林电子科技大学 一种基于机器学习的联盟链异常检测系统及其检测方法
CN112068978B (zh) * 2020-08-27 2022-06-10 恒宝股份有限公司 View-change二次启动定时器的定时期限延长方法及装置
CN111813795B (zh) * 2020-08-28 2020-12-04 支付宝(杭州)信息技术有限公司 在区块链网络中确认交易的方法及装置
CN111988203B (zh) * 2020-09-03 2022-08-23 深圳壹账通智能科技有限公司 节点选举方法、装置及存储介质
CN111930847B (zh) * 2020-09-16 2021-01-08 深圳壹账通智能科技有限公司 基于区块链的数据处理方法、装置及存储介质
CN112153136B (zh) * 2020-09-21 2022-04-22 中国电子科技网络信息安全有限公司 一种新型区块链共识算法rbft的实现方法
CN112422341B (zh) * 2020-11-18 2021-09-28 腾讯科技(深圳)有限公司 区块链网络的故障检测方法及相关设备
CN112532436B (zh) * 2020-11-23 2024-05-28 京东科技控股股份有限公司 一种区块链节点状态转换方法及区块链系统
CN112636905B (zh) * 2020-12-11 2022-02-15 北京航空航天大学 基于多角色的可扩展共识机制的系统及方法
CN112671761B (zh) * 2020-12-22 2022-08-05 网易(杭州)网络有限公司 区块链的节点处理方法、装置、节点设备及存储介质
CN112804091B (zh) * 2020-12-31 2023-07-25 北京百度网讯科技有限公司 联盟网络的运行实现方法、装置、设备及存储介质
CN113010337B (zh) * 2021-01-21 2023-05-16 腾讯科技(深圳)有限公司 故障检测方法、总控节点、工作节点及分布式系统
CN113364874B (zh) * 2021-06-09 2022-06-10 网易(杭州)网络有限公司 基于区块链的节点同步方法、装置、存储介质及服务器
US11651110B2 (en) * 2021-07-08 2023-05-16 Dell Products, L.P. Hardware device mutual authentication system and method for a baseboard management controller (BMC)
US11915014B2 (en) 2021-08-18 2024-02-27 Microsoft Technology Licensing Consensus based determination of stable configuration
CN113761062A (zh) * 2021-08-26 2021-12-07 浙商银行股份有限公司 一种自适应共识算法切换方法、设备及存储介质
CN113779145A (zh) * 2021-08-27 2021-12-10 浙商银行股份有限公司 一种区块链吞吐量提升系统及方法
CN113810497B (zh) * 2021-09-17 2022-07-26 北京邮电大学 基于区块链的医疗数据共享方法和装置
CN113570357B (zh) * 2021-09-26 2021-12-17 青岛理工大学 一种动态分层的高效pbft算法
CN113837758A (zh) * 2021-09-27 2021-12-24 深圳前海微众银行股份有限公司 一种区块链系统的共识方法及装置
US11601326B1 (en) * 2021-09-28 2023-03-07 Sap Se Problem detection and categorization for integration flows
CN114089744B (zh) * 2021-11-01 2023-11-21 南京邮电大学 一种基于改进Raft算法选择车辆队列领航车的方法
KR102620994B1 (ko) * 2021-11-04 2024-01-05 모비두 주식회사 라이브 커머스에서의 데이터 처리 시스템
CN114448995A (zh) * 2021-12-24 2022-05-06 苏州纳智天地智能科技有限公司 基于raft选主策略的分布式计算方法
CN114225381B (zh) * 2022-01-07 2022-07-19 广州炫动信息科技有限公司 基于区块链分布式共识算法的战斗数据处理方法及系统
CN114553508B (zh) * 2022-02-12 2023-06-30 中国银联股份有限公司 一种数据访问方法及装置
CN114185997B (zh) * 2022-02-17 2022-05-13 天津眧合数字科技有限公司 一种基于区块链的宠物信息可信存储系统
CN114760135B (zh) * 2022-04-19 2023-03-28 浙江大学 一种区块链容错共识方案的优化方法
CN115119230A (zh) * 2022-05-09 2022-09-27 成都市联洲国际技术有限公司 确定主设备和从设备的方法、装置、设备及存储介质
CN117221337A (zh) * 2022-06-02 2023-12-12 腾讯科技(深圳)有限公司 区块链共识方法、装置、介质及电子设备
CN115276999B (zh) * 2022-06-10 2024-03-22 大连理工大学 一种基于信任模型的自适应切换高效容错共识方法
CN115174447B (zh) * 2022-06-27 2023-09-29 京东科技信息技术有限公司 一种网络通信方法、装置、系统、设备及存储介质
CN115134320B (zh) * 2022-08-25 2023-01-03 四川汉唐云分布式存储技术有限公司 一种基于消息分发确定时序的交易系统
CN116192692A (zh) * 2022-12-30 2023-05-30 蚂蚁区块链科技(上海)有限公司 一种区块链网络中的共识数据分发方法和区块链网络
CN116074328B (zh) * 2023-03-01 2023-06-27 中国信息通信研究院 区块链网络中的区块传输方法、装置、设备和介质
CN116488946B (zh) * 2023-06-21 2023-09-15 积至网络(北京)有限公司 基于持续多模表决的恶意节点检测方法
CN117220884A (zh) * 2023-09-05 2023-12-12 上海雷龙信息科技有限公司 一种数字签名交互验证方法、系统、设备和介质

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998042019A1 (en) * 1997-03-18 1998-09-24 Telefonaktiebolaget Lm Ericsson (Publ) Trench-isolated bipolar devices
CN100539602C (zh) * 2002-03-27 2009-09-09 国际商业机器公司 瞬变网络中的动态寻址
US7451321B2 (en) * 2003-10-07 2008-11-11 Joseph Ernest Dryer Electronic signature management method
CN1937840B (zh) * 2005-09-19 2011-04-13 华为技术有限公司 一种移动终端切换过程中获得安全联盟信息的方法及装置
CN101022647B (zh) * 2006-02-15 2010-09-08 华为技术有限公司 切换处理过程中确定安全协商参数的实现方法及装置
US7630944B2 (en) * 2006-03-17 2009-12-08 Novell, Inc. Method for consensus decision making in a distributed system
CN101083658A (zh) * 2007-07-13 2007-12-05 浙江大学 一种角度随机中继协议实现方法
CN101110762A (zh) * 2007-08-22 2008-01-23 华中科技大学 一种Ad hoc网络安全路由方法
CN101483516A (zh) * 2008-01-07 2009-07-15 华为技术有限公司 安全控制的方法及其系统
US7937482B1 (en) * 2008-03-27 2011-05-03 Amazon Technologies, Inc. Scalable consensus protocol
US8156333B2 (en) * 2008-05-29 2012-04-10 Red Hat, Inc. Username based authentication security
US20150006895A1 (en) * 2009-06-01 2015-01-01 Maidsafe Foundation Distributed network system
US8856593B2 (en) * 2010-04-12 2014-10-07 Sandisk Enterprise Ip Llc Failure recovery using consensus replication in a distributed flash memory system
US10614098B2 (en) * 2010-12-23 2020-04-07 Mongodb, Inc. System and method for determining consensus within a distributed database
US8918392B1 (en) 2012-03-29 2014-12-23 Amazon Technologies, Inc. Data storage mapping and management
CN102739656A (zh) * 2012-06-12 2012-10-17 北京英华高科科技有限公司 一种控制非主节点类型和规模的方法和系统
EP2976714B1 (en) 2013-03-20 2017-05-03 NEC Corporation Method and system for byzantine fault tolerant data replication
US9686161B2 (en) 2013-09-16 2017-06-20 Axis Ab Consensus loss in distributed control systems
US9690675B2 (en) * 2014-07-17 2017-06-27 Cohesity, Inc. Dynamically changing members of a consensus group in a distributed self-healing coordination service
CL2015003766A1 (es) * 2015-12-30 2016-08-05 Univ Chile Sistema y método para comunicaciones electrónicas seguras mediante hardware de seguridad basado en criptografía umbral
US10282457B1 (en) * 2016-02-04 2019-05-07 Amazon Technologies, Inc. Distributed transactions across multiple consensus groups
CN105975868A (zh) * 2016-04-29 2016-09-28 杭州云象网络技术有限公司 一种基于区块链的证据保全方法及装置
CN106060036B (zh) * 2016-05-26 2019-07-16 布比(北京)网络技术有限公司 去中心化共识方法及装置
CN106445711B (zh) 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法
CN106503589A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 区块链交易信息正确性的校验方法、装置及系统
CN106534273B (zh) * 2016-10-31 2022-04-15 中金云金融(北京)大数据科技股份有限公司 区块链元数据存储系统及其存储方法与检索方法
CN106487801B (zh) * 2016-11-03 2019-10-11 江苏通付盾科技有限公司 基于区块链的信息验证方法及装置
CN107391320B (zh) * 2017-03-10 2020-07-10 创新先进技术有限公司 一种共识方法及装置
CN111327703B (zh) * 2017-03-28 2022-05-31 创新先进技术有限公司 一种基于区块链的共识方法及装置
CN106789095B (zh) * 2017-03-30 2020-12-08 腾讯科技(深圳)有限公司 分布式系统及消息处理方法
US10768085B2 (en) * 2017-07-18 2020-09-08 Cornell University Resonantly-driven drop contact-line mobility measurement
US20190306173A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Alert smart contracts configured to manage and respond to alerts related to code
KR102193549B1 (ko) * 2018-11-07 2020-12-23 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 실용적 비잔틴 장애 허용 블록체인 합의 및 노드 동기화의 용이화
ES2862428T3 (es) * 2019-03-18 2021-10-07 Advanced New Technologies Co Ltd Recuperación de tiempo de inactividad de sistema de consenso
KR102227685B1 (ko) * 2019-03-29 2021-03-16 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 블록 체인 네트워크에서 민감 데이터 요소를 관리하는 방법
US11611439B2 (en) * 2019-06-11 2023-03-21 Celo Foundation Tree structure for byzantine fault tolerance
US11343073B2 (en) * 2019-06-18 2022-05-24 Electronics And Telecommunications Research Institute Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance
US20210099312A1 (en) * 2019-09-27 2021-04-01 Cypherium Blockchain Inc. Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021520574A (ja) * 2019-11-06 2021-08-19 アリペイ (ハンジョウ) インフォメーション テクノロジー カンパニー リミテッドAlipay (Hangzhou) Information Technology Co., Ltd. 誤り訂正符号に基づく共有されたブロックチェーンデータの記憶のデータセキュリティ
JP7004423B2 (ja) 2019-11-06 2022-01-21 アリペイ (ハンジョウ) インフォメーション テクノロジー カンパニー リミテッド 誤り訂正符号に基づく共有されたブロックチェーンデータの記憶のデータセキュリティ
JP2023509889A (ja) * 2020-05-21 2023-03-10 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム
JP7398000B2 (ja) 2020-05-21 2023-12-13 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム

Also Published As

Publication number Publication date
CN110445619B (zh) 2020-10-16
CN106789095A (zh) 2017-05-31
US20220091918A1 (en) 2022-03-24
WO2018177264A1 (zh) 2018-10-04
EP3605947B1 (en) 2023-01-11
US20190235946A1 (en) 2019-08-01
US11775377B2 (en) 2023-10-03
US11237896B2 (en) 2022-02-01
TWI662435B (zh) 2019-06-11
EP3605947A4 (en) 2020-12-30
CN110430064B (zh) 2020-12-04
CN110430064A (zh) 2019-11-08
CN110445619A (zh) 2019-11-12
EP3605947A1 (en) 2020-02-05
KR20190118631A (ko) 2019-10-18
KR102248454B1 (ko) 2021-05-04
CN106789095B (zh) 2020-12-08
JP6883106B2 (ja) 2021-06-09
TW201837777A (zh) 2018-10-16

Similar Documents

Publication Publication Date Title
JP6883106B2 (ja) 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体
US11516006B2 (en) Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system
CN112035889B (zh) 计算外包的区块链隐私验证方法、装置及计算机设备
EP3780553B1 (en) Blockchain-based transaction consensus processing method and apparatus, and electrical device
US11128522B2 (en) Changing a master node in a blockchain system
CN110351133B (zh) 用于区块链系统中的主节点切换处理的方法及装置
US11283634B2 (en) System and method for detecting replay attack
JP2020512708A5 (ja)
US11323475B2 (en) System and method for detecting replay attack
US20200128043A1 (en) System and method for detecting replay attack
US20200128044A1 (en) System and method for detecting replay attack
CN111212139A (zh) 对信任节点信息进行更新的方法及装置
EP3659060B1 (en) Consensus protocol for permissioned ledgers
CN113064764B (zh) 在区块链系统中执行区块的方法及装置
CN111582845A (zh) 区块链的跨链交易方法、装置以及电子设备
Bazzi et al. Clairvoyant state machine replication
CN112994891B (zh) 一种基于门限签名的交易请求共识方法和系统
CN108882230B (zh) 通话记录管理方法、装置及系统
CN112465516B (zh) 基于区块链网络的设备管理方法,相关设备及存储介质
CN111818152B (zh) 一种基于分布式网络的领导者选举的共识方法
CN117424904A (zh) 共识处理方法、装置、计算机设备和区块链系统

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190613

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190613

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200831

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200907

A524 Written submission of copy of amendment under article 19 pct

Free format text: JAPANESE INTERMEDIATE CODE: A524

Effective date: 20201125

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210426

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210507

R150 Certificate of patent or registration of utility model

Ref document number: 6883106

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250