WO2018177264A1 - 分布式系统、消息处理方法、节点、客户端及存储介质 - Google Patents

分布式系统、消息处理方法、节点、客户端及存储介质 Download PDF

Info

Publication number
WO2018177264A1
WO2018177264A1 PCT/CN2018/080574 CN2018080574W WO2018177264A1 WO 2018177264 A1 WO2018177264 A1 WO 2018177264A1 CN 2018080574 W CN2018080574 W CN 2018080574W WO 2018177264 A1 WO2018177264 A1 WO 2018177264A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
message
consensus
client
distributed system
Prior art date
Application number
PCT/CN2018/080574
Other languages
English (en)
French (fr)
Inventor
郭锐
李茂材
赵琦
张建俊
屠海涛
王宗友
梁军
朱大卫
陈立生
刘斌华
Original Assignee
腾讯科技（深圳）有限公司
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 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to JP2019531777A priority Critical patent/JP6883106B2/ja
Priority to EP18777404.7A priority patent/EP3605947B1/en
Priority to KR1020197027223A priority patent/KR102248454B1/ko
Publication of WO2018177264A1 publication Critical patent/WO2018177264A1/zh
Priority to US16/383,162 priority patent/US11237896B2/en
Priority to US17/542,971 priority patent/US11775377B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/0706—Error 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/0709—Error 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error 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/202—Error 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/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0847—Transmission error
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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/0442—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3236—Cryptographic 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/3239—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3236—Cryptographic 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/3242—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3247—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/83—Indexing scheme relating to error detection, to error correction, and to monitoring the solution involving signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy

Definitions

  • the present invention relates to communication technologies, and in particular, to a distributed system, a message processing method, a node, a client, and a storage medium.
  • Distributed systems are currently widely used computing systems, applied to blockchains, distributed service frameworks (such as ZooKeeper) and many other fields.
  • the node needs to form a consensus on the message to be processed from the client, that is, all nodes or majority nodes of the distributed system confirm the received message, and then synchronously store/process the message.
  • each node forms a consensus on the transaction record submitted by the client according to the consensus algorithm (ie, confirms the reliability of the transaction record), which will be at each node.
  • the maintenance of the blockchain storage ensures the consistency of the transaction records stored by each node.
  • the consensus algorithm adopted by the related technology implements the consensus algorithm to focus on the efficiency of consensus, or guarantees certain fault tolerance performance in the process of reaching consensus. Fault tolerance performance means that when there are faulty nodes or malicious nodes, most nodes can still be achieved. consensus.
  • the embodiments of the present invention provide a distributed system, a message processing method, a node, a client, and a storage medium, which can implement a reliable consensus of nodes in a distributed system for messages.
  • an embodiment of the present invention provides a distributed system, including:
  • the node is configured to determine, when the new consensus period arrives in the first consensus mode, the state of being in the master node or in the state of the slave node by performing an election operation;
  • the node when configured to be in the state of the master node, verifies the digital signature of the message sent by the client, and sends the message to the slave node;
  • the node is configured to, when in a state of the master node, receive an acknowledgement receipt notification that exceeds the predetermined number of the slave nodes, verify the digital signature of the acknowledgement receipt notification, and persist the storage of the message to the slave
  • the node sends a store message notification
  • the node when configured to be in the state of the slave node, returns a result to the client when receiving the message sent by the master node, and verifies the digital signature of the message received from the master node, and persists a message received from the master node;
  • the client is configured to determine an abnormal node in the distributed system according to a result returned when the slave node receives the message.
  • an embodiment of the present invention provides a message processing method, which can be applied to a node in a distributed system, including:
  • the nodes in the distributed system When a new consensus period arrives in the first consensus mode, the nodes in the distributed system perform an election operation, and determine the state of being in the master node or in the state of the slave node through the election operation;
  • the node When the node is in the state of the primary node, the node performs the following operations:
  • the result returned by the slave node when the message is received is used by the client to determine an abnormal node in the distributed system.
  • an embodiment of the present invention provides a message processing method, which can be applied to a client in a distributed system, including:
  • the client sends a message to the master node in the node of the distributed system, the message carrying the digital signature of the client;
  • the digital signature is used for the primary node to perform verification, and the received message carries the digital signature of the primary node and is sent to the secondary node in the distributed system;
  • the client determines an abnormal node in the distributed system according to a result returned when the slave node receives the message.
  • an embodiment of the present invention provides a node, which can be applied to a distributed system, where the node includes:
  • the election unit is configured to perform the election operation when the new consensus cycle arrives in the first consensus mode, and determine the state of being in the master node or the state of the slave node through the election operation;
  • a master node unit configured to receive a message of the client, verify a digital signature of the message, send the message to the slave node, and, when the node is in a state of a master node
  • the result returned by the slave node when the message is received is used by the client to determine an abnormal node in the distributed system.
  • an embodiment of the present invention provides a node, which can be applied to a distributed system, where the node includes one or more processors and a memory, and one or more programs, where the one or more programs Stored in a memory, the program may include one or more units each corresponding to a set of instructions, the one or more processors being configured to execute instructions to implement the application to the node provided by the embodiments of the present invention.
  • Message processing method the node includes one or more processors and a memory, and one or more programs, where the one or more programs Stored in a memory, the program may include one or more units each corresponding to a set of instructions, the one or more processors being configured to execute instructions to implement the application to the node provided by the embodiments of the present invention.
  • an embodiment of the present invention provides a client that can be applied to a distributed system, where the client includes:
  • a communication unit configured to send a message to a primary node in a node of the distributed system, the message carrying a digital signature of the client;
  • the digital signature is used for the primary node to perform verification, and the received message carries the digital signature of the primary node and is sent to the secondary node in the distributed system;
  • the communication unit is configured to receive a result returned by the slave node when receiving the message
  • a detecting unit configured to determine an abnormal node in the distributed system according to a result returned when the slave node receives the message.
  • an embodiment of the present invention provides a client that can be applied to a distributed system, where the client includes one or more processors and a memory, and one or more programs, where the one or more The program is stored in a memory, and the program may include one or more units each corresponding to a set of instructions, the one or more processors being configured to execute instructions to implement the application provided by the embodiments of the present invention.
  • the client's message processing method is described in detail below.
  • an embodiment of the present invention provides a storage medium, where stored executable instructions are used to cause a processor to execute the executable program, and implement a message processing method applied to a node provided by an embodiment of the present invention.
  • an embodiment of the present invention provides a storage medium, which is configured to execute an executable instruction, which is used to cause a processor to execute the executable program, and implement a message processing method applied to a client provided by an embodiment of the present invention.
  • Digital signature is used to ensure the reliability of communication in distributed systems: digital signature is adopted for both parties of any communication, that is, the digital signature of the message is carried when the message is sent, and the reliability of receiving the message is ensured by verifying the digital signature. Sex.
  • the slave node When the slave node receives the message sent by the master node, it directly returns the result to the client, and carries the necessary information such as a uniqueness field, a message sequence number, and a digital signature in the result, so that the client can directly refer to the slave node.
  • the returned result is used to determine that the abnormal node is efficiently detected from the case where the node has reached a consensus.
  • FIG. 1 is an optional structural diagram of a distributed system 100 applied to a blockchain system according to an embodiment of the present invention
  • FIG. 2 is an optional schematic diagram of a block structure provided by an embodiment of the present invention.
  • 3A is a schematic structural diagram of an optional hardware and software of a node 200 according to an embodiment of the present invention.
  • FIG. 3B is a schematic structural diagram of an optional hardware and software of the client 300 according to an embodiment of the present invention.
  • FIG. 4 is an optional schematic diagram of determining a master node and a slave node by performing an election operation in each node in a first consensus mode according to an embodiment of the present invention
  • FIG. 5 is an optional schematic flowchart of a node of a distributed system according to an embodiment of the present invention reaching a consensus in a first consensus mode and detecting a faulty node and a malicious node;
  • FIG. 6 is an optional schematic flowchart of providing a distributed system in a first consensus mode and a second mode according to an embodiment of the present invention
  • FIG. 7 is an optional schematic flowchart of providing a distributed system in a first consensus mode and a second mode according to an embodiment of the present invention
  • FIG. 8 is an optional schematic flowchart of a blockchain system according to an embodiment of the present invention using a RAFT algorithm to achieve consensus;
  • FIG. 9 is an optional schematic flowchart of a blockchain system according to an embodiment of the present invention using a PBFT algorithm to achieve consensus;
  • FIG. 10 is a schematic diagram of an operational state of implementing an adaptive consensus algorithm according to an embodiment of the present invention.
  • FIG. 11 is a schematic diagram of implementation of a consensus of a T-RAFT algorithm according to an embodiment of the present invention.
  • FIG. 12 is an optional schematic flowchart of switching back to the T-RAFT algorithm in the preparation phase of PBFT algorithm switching according to an embodiment of the present invention
  • FIG. 13 is an optional flowchart diagram of the blockchain system of the embodiment of the present invention switching from the consensus of the T-RAFT algorithm to the consensus of the PBFT algorithm;
  • FIG. 14 is an optional schematic flowchart of switching the consensus mode of the PBFT algorithm of the blockchain system to the consensus mode of the T-RAFT algorithm according to the embodiment of the present invention
  • FIG. 15 is a schematic diagram of an optional scenario in which a distributed system according to an embodiment of the present invention is applied to a federation chain system.
  • the node verifies the correctness of the message sent by other nodes (ie, any node of the distributed system except the node that sends the message), and if the verification succeeds, sends a confirmation to the node that sent the message. And the message is persisted for use in supporting subsequent queries.
  • the node verifies the validity of the new block submitted by other nodes (including the newly generated transaction record), and if the verification is successful, sends an acknowledgement to the node that sent the new block, and The new block is added to the end of the blockchain stored by the corresponding node to complete the consensus of the transaction records in the blockchain.
  • Consensus mode also known as consensus algorithm, is used to ensure that the nodes of the distributed system reach consensus.
  • the consensus mode can include the following types:
  • the first consensus model can achieve high consensus efficiency and can detect node failure or Byzantine problems (one message sent to the other party, the other party did not receive it, or the wrong information was received), but the Byzantine cannot be resolved.
  • the consensus mode of the problem exemplarily, the algorithm for implementing the first consensus mode includes a Paxos algorithm and a Recursive Algorithm for Fault Tolerance (RAFT).
  • RAFT Recursive Algorithm for Fault Tolerance
  • the second consensus model is used to solve the consensus model of the Byzantine problem.
  • the algorithms for implementing the second consensus model include: Byzantine Fault Tolerance (BFT) algorithm, Practical Byzantine Fault Tolerance (PBFT) algorithm, and Recursive Fault Tolerant Algorithm.
  • BFT Byzantine Fault Tolerance
  • PBFT Practical Byzantine Fault Tolerance
  • BFT-RAFT Byzantine Fault Tolerance Recursive Algorithm for Fault Tolerance
  • BFT-Paxos Byzantine Fault Tolerance
  • Consensus mode switching also known as consensus mode adaptation
  • the consensus algorithm used by distributed networks automatically adopts an algorithm with high consensus efficiency and can detect abnormal nodes (such as Byzantine nodes) to achieve the first time when the network environment is good.
  • Consensus mode when a malicious node or node is found to be wrong, automatically switches to support the solution of Byzantine fault tolerance to implement the second consensus mode.
  • a distributed system for implementing an embodiment of the present invention is formed by a client, a plurality of nodes (any form of computing device in the access network, such as a server, a user terminal) connected by a network communication, and the following is for a client and a node. The function is explained.
  • a node configured to determine a state of being in a master node or a state of being a slave node by performing an election operation when a new consensus period arrives in the first consensus mode
  • a node configured to verify a digital signature of a message sent by the client when in the state of the master node, and send the message to the slave node;
  • a node configured to receive an acknowledgment receipt notification that exceeds a predetermined number of slave nodes when in the state of the master node, verify the acknowledgment of the digital signature after receiving the notification, and store the stored message notification to the slave node;
  • the node is further configured to, when in the state of the slave node, return a result to the client when receiving the message sent by the master node, verify the digital signature of the message received from the master node, and send an acknowledgement receiving notification to the master node;
  • a node configured to, when in a state of a slave node, verify a digital signature of a stored message notification received from the master node, and persistently store the message received from the master node;
  • the client is configured to determine an abnormal node in the distributed system based on the result returned when the message is received from the node.
  • the client is further configured to verify the digital signature of the received result, compare the uniqueness field included in the received result with the uniqueness field of the sent message, and determine that the inconsistent uniqueness field corresponds to the slave node.
  • the faulty node determines that the slave node that did not return a result is a faulty node.
  • the client is further configured to compare the sequence number carried according to the received result with the sequence number of the sent message, and determine that the master node is a malicious node when the number of the slave nodes that send the inconsistent sequence number exceeds the inconsistency threshold. .
  • the client is further configured to determine that the primary node is a malicious node, or to determine that the node in the distributed system switches to the second consensus mode when there is a failed node in the secondary node.
  • the node is further configured to, when in the preparation phase of switching to the second consensus mode, hash the value of the message stored persistently by the node, and the hash value of the message stored persistently by the node in the distributed system Comparing, when the consistency is confirmed, the consistency confirmation is sent to the client, and the consistency confirmation carries the digital signature of the corresponding node;
  • the client is further configured to notify the node in the distributed system to return to the first consensus mode when receiving the consistency confirmation of all the nodes within the predetermined time, and notify the distributed system when the consistency confirmation of all the nodes is not received within the predetermined time.
  • the middle node continues to switch to the second consensus mode.
  • the node is further configured to, when in the preparation phase of switching to the second consensus mode, hash the value of the message stored persistently by the node, and the hash value of the message stored persistently by the node in the distributed system Comparing, when the confirmation is consistent, sending a data confirmation to the sending node of the message, and the data confirming carries the digital signature of the corresponding node;
  • the client is also configured to trigger a node in the distributed system when the node that has reached the consensus within the predetermined time does not receive the data confirmation of the node that has not reached the consensus, or when the node does not receive the data confirmation in the distributed system within the predetermined time. Continue to switch to the second consensus mode.
  • the node is further configured to switch to the first consensus mode when the state of the master node is in the state of the master node and the number of times counted in the second consensus mode exceeds the threshold number of the consensus of the master node, wherein The counted number is a count that forms a consensus with the slave node for the received message.
  • the node is further configured to, when in the state of the primary node, send a notification to the secondary node to switch to the first consensus mode when the counted number exceeds the threshold of the primary node consensus number, and receive the notification When all the slave nodes send a handover confirmation, they switch to the first consensus mode synchronously with the slave node.
  • the node is further configured to, when in the state of the slave node, receive a notification of switching to the first consensus mode, and count that the number of times the consensus is formed for the received message exceeds the threshold of the consensus number of slave nodes, to the master The node sends a handover confirmation.
  • the node is further configured to not receive the heartbeat information of the master node, or when the master node is a malicious node, determine the state of the master node or the state of the slave node by re-executing the election operation.
  • the node is further configured to send an election request to the node in the distributed system when the new consensus period arrives and the heartbeat information sent by any node is not received, when receiving the election confirmation returned by the predetermined number of nodes , converting the state of the master node and periodically sending heartbeat information to the nodes in the distributed system;
  • the election confirmation is sent by the node in the distributed system, and the digital signature carried by the selection request is verified before being sent;
  • the node is further configured to transition to the state of the slave node when the new consensus period arrives and the heartbeat information sent by the node in the distributed system is received.
  • FIG. 1 is an optional structural diagram of a distributed system 100 according to an embodiment of the present invention.
  • the node 200 (for any type of computing device in the access network, such as a server and a user terminal), further includes a client 300, and a node-to-peer (P2P, Peer To Peer) network is formed.
  • P2P node-to-peer
  • the P2P protocol is a running.
  • TCP Transmission Control Protocol
  • Routing the basic function of the node, used to support communication between nodes.
  • node 200 can also have the following functions:
  • the application is used for deployment in the blockchain, realizing specific services according to actual business requirements, recording data related to function realization to form record data, carrying digital signatures in the record data to indicate the source of the task data, and transmitting the record data Go to other nodes in the blockchain system (that is, any node that receives the recorded data in the blockchain system), and the other nodes add the record data to the temporary block when verifying the record data source and the integrity is successful.
  • the business implemented by the application includes:
  • Wallet which is used to provide the function of trading in electronic money, including initiating a transaction (ie, sending the transaction record of the current transaction to other nodes in the blockchain system, and after the other nodes verify the success, as a valid response to the acknowledgement transaction)
  • the transaction data of the transaction is stored in the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic money in the electronic money address.
  • the shared ledger is used to provide the functions of storing, querying and modifying the account data, and transmitting the record data of the operation of the account data to other nodes in the blockchain system, and the other nodes are validated as the acknowledgement account.
  • the valid response of the data, the record data is stored in the temporary block, and the confirmation can be sent to the node that initiated the operation.
  • a smart contract is a computerized protocol that can be used to enforce the terms of a contract, implemented by code deployed on a shared ledger for execution when certain conditions are met, and used to complete automation based on actual business requirements code.
  • the transaction for example, querying the logistics status of the goods purchased by the buyer, and transferring the buyer's electronic money to the address of the merchant after the buyer signs the goods; of course, the smart contract is not limited to executing the contract for the transaction, but also The contract for receiving the processed information.
  • Blockchain including a series of blocks that are connected to each other in the order in which they are generated. Once the new block is added to the blockchain, it will not be removed. The blockchain system is recorded in the block. Record data submitted by the middle node.
  • FIG. 2 is an optional schematic diagram of a block structure according to an embodiment of the present invention, where each block includes a hash value of the block storage transaction record (the block of the block) The hash value, and the hash value of the previous block, each block is connected by a hash value to form a blockchain.
  • the block may also include information such as a time stamp when the block is generated.
  • FIG. 3A is a schematic diagram of an optional hardware and software structure of a node 200 according to an embodiment of the present invention.
  • the node 200 includes a hardware layer, a driver layer, an operating system layer, and an application layer.
  • the structure of the node 200 shown in FIG. 3A is merely an example and does not constitute a limitation on the structure of the node 200.
  • the node 200 may set more components than FIG. 3A according to implementation requirements, or may omit Set some components.
  • the hardware layer of node 200 includes a processor 210 input/output interface 240, a storage medium 230, and a network interface 220, through which components can communicate via a system bus connection.
  • the processor 210 can be implemented by using a central processing unit (CPU), a microprocessor (MCU, Microcontroller Unit), an application specific integrated circuit (ASIC), or a Field-Programmable Gate Array (FPGA).
  • CPU central processing unit
  • MCU microprocessor
  • ASIC application specific integrated circuit
  • FPGA Field-Programmable Gate Array
  • the input/output interface 240 can be implemented using input/output devices such as a display screen, a touch screen, and a speaker.
  • the storage medium 230 may be implemented by using a non-volatile storage medium such as a flash memory, a hard disk, or an optical disk, or may be implemented by using a volatile storage medium such as a double data rate (DDR), which stores a method for executing a message processing method. Executable instructions.
  • a non-volatile storage medium such as a flash memory, a hard disk, or an optical disk
  • a volatile storage medium such as a double data rate (DDR), which stores a method for executing a message processing method.
  • DDR double data rate
  • the network interface 220 provides the processor 210 with access capabilities of external data, such as a remotely located storage medium 230.
  • external data such as a remotely located storage medium 230.
  • the network interface 220 can be implemented, such as based on Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access.
  • CDMA Code Division Multiple Access
  • WCDMA Wideband Code Division Multiple Access
  • Their evolutionary systems such as (WCDMA, Wideband Code Division Multiple Access) and their evolutionary systems.
  • the driver layer includes middleware 250 for the operating system 260 to identify and communicate with the hardware layer components, such as a collection of drivers for the various components of the hardware layer.
  • Operating system 260 is configured to provide a user-oriented graphical interface that displays various intermediate results and end results of various application processing based on the blockchain.
  • the application layer includes a consensus mechanism 270 configured to implement consensus between nodes (configured to adaptively switch between the first consensus mode and the second consensus mode), and functions implemented by the node based on the distributed system such as the electronic money wallet 280, smart Contract 290, etc., includes a first consensus mode and a second consensus mode.
  • a consensus mechanism 270 configured to implement consensus between nodes (configured to adaptively switch between the first consensus mode and the second consensus mode), and functions implemented by the node based on the distributed system such as the electronic money wallet 280, smart Contract 290, etc., includes a first consensus mode and a second consensus mode.
  • the application layer consensus mechanism 270 of the node 200 provided in FIG. 3A includes:
  • the election unit 2701 is configured to, when the new consensus period arrives in the first consensus mode, the other nodes in the distributed system of the node 200 are in the state of the master node or in the state of the slave node by performing the election operation;
  • the master node unit 2702 is configured to receive a message of the client when the node 200 is in the state of the master node, send a message to the slave node after verifying the digital signature of the message; and, when receiving the acknowledgement reception notification exceeding the predetermined number of slave nodes After verifying that the digital signature of the received message is received, the stored message is persisted, and the stored message notification is sent to the slave node;
  • the result returned by the node when the message is received is used by the client to determine an abnormal node in the distributed system.
  • the slave node unit 2703 is configured to: when the node 200 is in the state of the slave node, verify the received digital signature of the stored message notification and persist the stored message; the message is used by the client to determine the abnormal node;
  • the slave node unit 2703 is configured to, when the node 200 is in the state of the slave node, perform the following operations: receiving the message sent by the master node and returning the result to the client, verifying the digital signature of the received message An acknowledgment receipt notification is sent to the master node, and the received digital message signature of the stored message notification is verified to persist the stored message.
  • the slave node when the node 200 is in the state of the slave node, the slave node returns a result to the client carrying the following information: the uniqueness field of the message, the digital signature of the slave node; the result is used for verification by the client.
  • the digital signature compares the uniqueness field included in the result with the uniqueness field of the sent message, determines that the slave node corresponding to the inconsistent uniqueness field is an error node, and determines that the slave node that does not return the corresponding result is a faulty node.
  • the result returned by the slave node carries the sequence number of the message received by the slave node, and the result carries the sequence number used for the client to carry the sequence number carried by the received result.
  • the master node is a malicious node.
  • the switching unit 2704 is further configured to be configured to switch to the second consensus mode in response to the trigger of the client when the client determines that the master node is a malicious node or determines that there is a faulty node in the slave node.
  • the switching unit 2704 is further configured to perform the following operations when the node 200 is in the preparation phase of switching to the second consensus mode:
  • the hash value of the message stored persistently by the node 200 is compared with the hash value of the message stored persistently by the node in the distributed system (ie, the node of the distributed system except the node 200), and sent to the client when the confirmation is consistent.
  • Consistency confirmation the consistency confirmation carries the digital signature of the corresponding node, and is used for verification when the client receives the consistency confirmation;
  • the user switches to the first consensus mode in response to the notification of the client;
  • the user continues to switch to the second consensus mode in response to the notification of the client.
  • the switching unit 2704 is further configured to perform the following operations when the node 200 is in the preparation phase of switching to the second consensus mode:
  • the data confirmation carries the digital signature of the corresponding node
  • the data is confirmed, and the node configured for the client to reach the consensus within the predetermined time does not receive the data confirmation of the node that has not reached the consensus, or the node in the distributed system does not receive the data confirmation sent by the other node within the predetermined time.
  • the node triggering the distributed system continues to switch to the second consensus mode.
  • the master node unit 2702 is further configured to: when the node 200 is in the state of the master node, and in the second consensus mode, it is counted that the number of times the slave node forms a consensus with the received message exceeds the master node consensus number threshold. When switching from the slave node to the first consensus mode.
  • the master node unit 2702 is further configured to send a notification to the slave node to switch to the first consensus mode when the number of times counted in the second consensus mode exceeds the threshold value of the master node consensus number, and receive all the notifications
  • the synchronization with the slave node is switched to the first consensus mode; wherein the counted number is a count that forms a consensus with the slave node for the received message.
  • the slave node unit 2703 is further configured to perform the following operations when the node is in the state of the slave node: when receiving the notification of switching to the first consensus mode, counting the number of times the consensus is formed for the received message, When the counted number exceeds the threshold of the slave node consensus number, a handover confirmation is sent to the master node.
  • the election unit 2701 is further configured to: when the heartbeat information of the primary node is not received, or when the primary node is a malicious node, and the node in the distributed system (ie, except the node 200 in the distributed system) The node is determined to be in the state of the master node or in the state of the slave node by performing an election operation.
  • the election unit 2701 is further configured to send an election request to the node in the distributed system when the new consensus period arrives and the heartbeat information sent by the node in the distributed system is not received, and the election request carries the node.
  • the digital signature when receiving the election confirmation returned by the predetermined number of nodes, converting to the state of the primary node, periodically transmitting heartbeat information to the nodes in the distributed system to maintain the state of the primary node; wherein the election is confirmed as a node in the distributed system Verify the digital signature carried by the selected request and send it;
  • the election unit 2701 is further configured to transition to a state of the slave node when the new consensus period arrives and the heartbeat information sent by the node in the distributed system is received.
  • the client can be a combination of hardware and a software environment deployed on the hardware. Based on this, the client can also be called a client device, configured to implement mining, management nodes, and deployment of smart contracts.
  • FIG. 3B is a schematic diagram of an optional hardware and software structure of a client according to an embodiment of the present invention.
  • the client 300 includes a hardware layer, a driver layer, an operating system layer, and an application layer. It should be understood by those skilled in the art that the structure of the client 300 illustrated in FIG. 3B is merely an example and does not constitute a limitation on the structure of the client 300. For example, the client 300 can set more components than FIG. 3B according to implementation requirements, or omit setting partial components according to implementation needs.
  • the hardware layer of the client 300 includes a processor 310 input/output interface 340, a storage medium 330, and a network interface 320 through which components can communicate via a system bus connection.
  • the processor 310 can be implemented using a CPU, an MCU, an ASIC, or an FPGA.
  • the input/output interface 340 can be implemented using input/output devices such as a display screen, a touch screen, and a speaker.
  • the storage medium 330 may be implemented by a non-volatile storage medium such as a flash memory, a hard disk, an optical disk, or the like, or may be implemented by DDR, in which executable instructions for executing the above-described communication state processing method are stored.
  • the network interface 320 provides the processor 310 with access capabilities of external data, such as an off-site set storage medium 330.
  • external data such as an off-site set storage medium 330.
  • the network interface 320 can implement communications such as CDMA, WCDMA, etc. communication systems and their evolutionary systems.
  • the driver layer includes a middleware 350 configured to identify the hardware layer by the operating system 360 and to communicate with various components of the hardware layer, such as a collection of drivers for the various components of the hardware layer.
  • the operating system 360 is configured to provide a user-oriented graphical interface that displays various intermediate results and end results of various application processing based on the blockchain.
  • the application layer is configured to send a message to a node of the distributed system, so that each node obtains a consensus for the message to persist the stored message; detects an abnormal node in the distributed system, and triggers the node to switch the consensus mode.
  • FIG. 3B provides a functional structure of the application layer of the client 300, including the management node 380, the deployment smart contract 390, and the consensus 370.
  • Consensus 370 includes:
  • the communication unit 3701 is configured to send a message to the primary node in the node of the distributed system, where the message carries the digital signature of the client;
  • the digital signature is used for the primary node to perform verification, and the received message carries the digital signature of the primary node and is sent to the secondary node in the distributed system;
  • the communication unit 3701 is configured to receive a result returned by the slave node when receiving the message
  • the detecting unit 3702 is configured to determine an abnormal node in the distributed system according to a result returned when the message is received from the node.
  • the detecting unit 3702 is further configured to: after verifying the digital signature of the received result, compare the received result including the uniqueness field with the uniqueness field of the sent message, and determine the slave node corresponding to the inconsistent uniqueness field.
  • the faulty node, and the slave node that determines that the corresponding result is not returned, is the faulty node.
  • the detecting unit 3702 is further configured to compare the sequence number carried according to the received result with the sequence number of the sent message, and when the number of the slave nodes that send the inconsistent sequence number exceeds the inconsistency threshold, determine that the master node is Malicious node.
  • the method further includes: a switching unit 3703 configured to determine that the primary node is a malicious node, or to determine that the node in the distributed system switches to the second consensus mode when the faulty node exists in the slave node.
  • the switching unit 3703 is further configured to notify all nodes to return to the first consensus mode when receiving the consistency confirmation of all the nodes within a predetermined time; when the consistency confirmation of all the nodes is not received within the predetermined time , notifying all nodes to continue switching to the second consensus mode;
  • the consistency confirmation carries a digital signature of the node, which is sent when the node is in a preparation phase of switching to the second consensus mode, and determines a hash of the persistently stored message of the node before sending The value is consistent with the hash value of the message stored persistently by the node in the distributed system.
  • the switching unit 3703 is further configured to: when the node that has reached the consensus within the predetermined time does not receive the data acknowledgement of the node that does not reach the consensus, or the node in the distributed system does not receive the other node in the predetermined time within the predetermined time.
  • the node in the distributed system is triggered to continue to switch to the second consensus mode;
  • the data acknowledgement carries the digital signature of the corresponding node, and is sent by the node 200 when it is in the preparation phase of switching to the second consensus mode, and determines the hash value and distributed of the persistently stored message of the node 200 before transmitting.
  • the hash values of the persistently stored messages of the nodes in the system ie, nodes other than nodes 200 in the distributed system) are consistent.
  • the node adopts the first consensus mode to form a consensus on the message from the client, and the first consensus mode can ensure the efficiency of the node to form a consensus.
  • the embodiment of the present invention does not exclude the distributed.
  • the nodes of the system adopt a second consensus mode to form a consensus on messages from the client.
  • FIG. 5 is a schematic diagram of a node of a distributed system according to an embodiment of the present invention reaching a consensus in a first consensus mode, and detecting a faulty node and a malicious node.
  • An optional flow diagram is illustrated in conjunction with steps 101 through 108.
  • Step 101 When a new consensus period arrives in the first consensus mode, the plurality of nodes of the distributed system determine the state of the master node and the state of the slave node by performing an election operation.
  • a node of a distributed system has three types (also called states): a competing node, a master node, and a slave node; each node of the distributed system starts a timer in a new consensus for forming a consensus When the period arrives, each node is a competing node, and each competing node strives to be converted into a master node by performing a selection operation (a distributed system has only one legitimate master node), and a competing node that has not become a master node is converted into a slave node.
  • a selection operation a distributed system has only one legitimate master node
  • each competing node it will detect whether the heartbeat information sent by other nodes is received at the beginning of the new consensus period. If it is not received, indicating that the master node has not been generated in the current consensus period, the competing node sends elections to other nodes.
  • the request carries the digital signature of the sending node in the selection request, and after the receiving node verifies that the digital signature of the selection request is successful, determines the reliability of the election request, that is, sends an election confirmation to the sending node, when a node receives enough (eg, the predetermined number can be When half of the nodes are elected, the other nodes are converted to the master node, and the heartbeat information is periodically sent to other nodes, and the competing node that receives the heartbeat information is converted into the slave node.
  • a sufficient number of election acknowledgments are not received by any of the nodes during a consensus period, a new consensus cycle is started to continue the selection operation until the master node and the slave node are determined.
  • FIG. 4 is an optional schematic diagram of determining a master node and a slave node by performing an election operation in each node in the first consensus mode according to an embodiment of the present invention.
  • any node In a distributed system, any node is in one of three states at any one time: the primary node, the secondary node, and the competing node; in the vast majority of the normal operation of the distributed system, there will be One master node, the other nodes are slave nodes, and the master node accepts the client's message.
  • each term can be any length, and the term is numbered with consecutive integers.
  • Each term first conducts the election of the primary node. In the election phase, multiple competing nodes compete to become the primary node. Once a node becomes the primary node, the other competing nodes become the secondary nodes, and the nodes that become the primary node will be consistent during the term. As the master node, if the master node fails, other nodes will be elected during the new term.
  • each node maintains the current term count, and the communication between each node contains the count of the term, each Each node will update its own term count to the highest detected value when it detects that the term count maintained by itself is lower than the term count maintained by other nodes.
  • the heartbeat mechanism is used to trigger the election operation of the primary node.
  • all nodes are initialized to the slave node state, the term is set to 0, and the timer is started. After the timer expires, the slave node is converted into a competition node. Convert to a competing node and do the following:
  • Step 1011 increasing the count of the term of the node
  • Step 1012 starting a new timer
  • Step 1013 Send a Request Vote remote procedure call protocol (RPC) message to other nodes, and wait for other nodes to reply to the election confirmation.
  • RPC remote procedure call protocol
  • election confirmation of the majority node is received before the timer expires, it is converted to the primary node. If an additional entry (Append Entries) heartbeat RPC message with additional content sent by other nodes is received, indicating that other nodes have been selected as the master node, it is converted into a slave node. If the timer expires and has not received any of the above two types of information, a new election operation is performed.
  • the node After receiving the voting of the majority node as the primary node, the node will immediately send the Append Entries heartbeat RPC message to all the nodes. After receiving the Append Entries heartbeat RPC message, the competing node converts to the secondary node and the election operation ends.
  • step 102 the client digitally signs the message and sends a message carrying the digital signature to the master node.
  • the client uses its own private key to encrypt the message (which does not exclude extracting the digest from the message using any digest algorithm in the embodiment of the present invention) to form a digital signature.
  • Step 103 After the digital signature of the primary node verification message is successful, the digital signature of the primary node is added to the message, and the message is sent to the secondary node.
  • the master node decrypts the digital signature using the public key to obtain a digest, and compares it with the digest algorithm (consistent with the digest algorithm used by the client). If it is consistent, the source of the message is reliable, and the private key of the master node is used for the message.
  • the abstract encryption forms the digital signature of the master node, and the digital signature of the master node is added to the message to be sent to each slave node.
  • the digital signature of the client carried by the message may or may not be carried; if the primary node is inconsistent, the message may be discarded and the client may be requested to retransmit.
  • Step 104 After receiving the message sent by the master node, the slave node verifies the digital signature of the received message, and after sending the verification, sends a confirmation reception notification to the master node, and sends the result to the client.
  • the slave node decrypts the digital signature of the received message using the public key to obtain a digest, and compares it with the digest algorithm (consistent with the digest algorithm used by the master node). If it is consistent, the source of the message is reliable, and the private node is utilized.
  • the key pair confirms that the digest of the received notification is encrypted to form a digital signature of the slave node and returns to the master node.
  • Sending results from a node to a client includes two cases:
  • the slave node In the current consensus period, if the slave node first receives the message sent by the master node, the result sent to the client includes: the sequence number of the received message; the uniqueness field of the message (the field in the message can be distinguished from The field of other messages); the slave node's digital signature for the result is obtained by encrypting the summary of the result from the private key of the node.
  • the result sent to the client includes: the uniqueness field of the message (the field in the message, which can distinguish the field from other messages);
  • the slave node's digital signature for the result is obtained by encrypting the summary of the result from the private key of the node.
  • Step 105 The master node verifies that the digital signature carried by the acknowledgment receiving notification is received. After continuously receiving the acknowledgment receiving notification sent by the predetermined number of slave nodes, the persistent storage message is sent, and the storage message notification is sent to the slave node.
  • the stored message notification carries a digital signature of the primary node for storing the message notification, and the digital signature is obtained by encrypting the digest of the stored message notification using the private key of the primary node.
  • the master node stores the message in a non-volatile manner.
  • the node (master node) that receives the transaction record submitted by the client stores the transaction record in the blockchain. In the new block.
  • Step 106 After receiving the storage message notification from the node, after verifying that the carried digital signature is successful, the stored message is locally persisted at the slave node, and the stored message acknowledgement carrying the digital signature is sent to the master node.
  • the slave node uses the public key to decrypt the received digital signature of the stored message notification to obtain a digest, and compares it with the digest algorithm (consistent with the digest algorithm used by the master node). If they are consistent, the source of the stored message notification is reliable, and the source is reliable.
  • the digest of the slave node's private key to store the message acknowledgement forms a digital signature of the slave node, and the stored message with the digital signature is confirmed to return to the master node.
  • Step 107 The master node verifies the received digital signature of the stored message confirmation. If more than half of the slave node's stored message is received and the digital signature is successfully verified, the stored message confirmation is sent to the client.
  • the stored message acknowledgement sent by the master node to the client carries the digital signature of the master node, and is used by the client to verify the reliability of the stored message source.
  • Step 108 The result returned by the client master node and the slave node when receiving the message, detecting the abnormal node: determining whether the master node is a malicious node, and determining whether there is a fault node in the slave node.
  • the received result includes the uniqueness field and the uniqueness of the sent message. If the inconsistency is determined, the slave node that determines the uniqueness field of the inconsistency is the error node, and the slave node that has not returned the result is determined to be the faulty node.
  • the primary node when receiving the message sent by the primary node, the result sent by the secondary node to the client includes, in addition to the uniqueness field and the digital signature, The serial number of the received message is further included, so that the client can compare the serial number carried by the received result with the serial number of the sent message, and when the number of the slave nodes that send the inconsistent sequence number exceeds the threshold, the newly generated The master node sends a forged message to the slave node, thus determining that the master node is a malicious node.
  • the digital signature is adopted, that is, the sender carries the digital signature of the message when sending the message.
  • the digest of the message is encrypted using the private key of the sender's asymmetric encryption algorithm to form the sender's number.
  • Signature the receiver ensures the reliability of the message by verifying the digital signature, that is, the signature of the read message uses the public key of the asymmetric encryption algorithm (to ensure that the receiver and the sender use the same asymmetric encryption algorithm, the receiver knows the public key in advance)
  • the decryption is performed, and the digest obtained by the decryption is compared with the digest extracted from the message. If the digital signature verification is consistently stated, the message sent by the sender is reliable.
  • the slave node When the slave node receives the message sent by the master node, it directly returns the result to the client, and carries the necessary information such as the uniqueness field, the message sequence number and the digital signature in the result, so that the client can directly refer to the slave node. As a result of the return, it is determined that the node has reached a consensus, and the abnormal node can be easily detected.
  • the embodiment of the present invention provides the presence in the distributed system.
  • the abnormal node switches the distributed system to the second consensus mode with better fault tolerance.
  • FIG. 6 is an optional schematic flowchart of providing a distributed system in a first consensus mode and a second mode according to an embodiment of the present invention, and is described in conjunction with steps 109 to 112.
  • Step 109 When the client determines that there is an abnormal node in the distributed system, triggering the node in the distributed system to switch from the second consensus mode.
  • the client broadcasts a notification of switching to the second consensus mode to the node of the distributed system.
  • Step 110 The node of the distributed system sends a hash value and a digital signature of the persistently stored message of the corresponding node to the other nodes in the preparation phase of switching to the second consensus mode.
  • the node 200 sends a hash value and a digital signature of the persistently stored message of the node 200 to the node of the distributed system in the preparation phase of switching to the second consensus mode.
  • Step 111 The receiving node of the message receives the hash value and the digital signature sent by all other nodes in the distributed system (ie, all nodes except the receiving node), and after verifying that the digital signature of the hash value is successful, the hash is hashed. The value is compared to the hash value of the message stored by the receiving node persistently, and if all are consistent, a consistency confirmation is sent to the client.
  • the node 1 that receives the notification in the distributed system sends (eg, broadcasts) the hash value of the persistently stored message in the node and the digital signature to the node 2-N in the preparation phase of switching to the second consensus mode ( N is the number of nodes in the distributed system.
  • N is the number of nodes in the distributed system.
  • node 1 receives the hash value sent by node 2 to node N.
  • the hash value carries the digital signature of the corresponding node.
  • node 2 After node 1 verifies that the digital signature is successful, node 2
  • the hash value sent to the node N is compared with the hash value of the message stored by the node 1 persistently, and if all are consistent, the node 1 sends a consistency confirmation to the client.
  • Step 112 The client detects whether a consistency confirmation of all nodes is received, and if yes, notifies the node of the distributed system to continue to switch to the first consensus mode; if not, notifies the node of the distributed system to continue to switch to the second consensus. mode.
  • the client receives the consistency confirmation sent by all the nodes in the distributed system, it indicates that the abnormal node is detected due to network fluctuation or discarding the response message, and there is no abnormal node in the distributed system, so the mode is switched back to the first consensus mode. To ensure the efficiency of consensus between nodes.
  • the client does not receive the consistency confirmation sent by all the nodes in the distributed system within the predetermined time, it indicates that the abnormal node does exist in the distributed system, and then the node in the distributed system is notified to continue to switch to the second consensus mode.
  • FIG. 7 is an optional schematic flowchart of providing a distributed system in a first consensus mode and a second mode according to an embodiment of the present invention, including the following steps:
  • Step 113 When the client determines that there is an abnormal node in the distributed system, triggering the node in the distributed system to switch from the second consensus mode.
  • the client broadcasts a notification of switching to the second consensus mode to the node of the distributed system.
  • Step 114 The node of the distributed system sends a hash value and a digital signature of the message stored by the corresponding node to the other node in the preparation phase of switching to the second consensus mode.
  • Step 115 The receiving node of the message receives the hash value and the digital signature sent by other nodes in the distributed system, and after verifying that the digital signature of the hash value is successful, the hash value is hashed with the message stored by the receiving node. For comparison, if they match, a data confirmation is sent to the sending node of the message.
  • the node 1 that receives the notification in the distributed system sends (eg, broadcasts) the hash value of the persistently stored message in the node and the digital signature to the node 2-N in the preparation phase of switching to the second consensus mode ( N is the number of nodes in the distributed system.
  • N is the number of nodes in the distributed system.
  • node 1 receives the hash value sent by node 2 to node N.
  • the hash value carries the digital signature of the corresponding node.
  • node 2 After node 1 verifies that the digital signature is successful, node 2
  • the hash value sent to the node N is compared with the hash value of the message stored by the node 1 persistently. If all are identical, the node 1 sends a data acknowledgement to the node 2 to the node N respectively.
  • Step 116 The client confirms that the node that triggered the distributed system returns to the first consensus mode according to the data sent by each node, or the node that triggers the distributed system continues to switch to the second consensus mode.
  • the hash value of the message stored by the node persistently and the digital signature of the sending node are broadcast to other nodes; for the receiving node of the hash value, the number of the received hash value is verified After the signature, the received hash value is compared with the hash value of the receiving node storage message, and when the comparison is consistent, the data acknowledgement is sent to the sending node of the corresponding hash value, indicating that the messages stored by the two nodes are consistent.
  • Case 1 For a predetermined time, for the receiving node for data confirmation, if the data confirmation of the transmission of other nodes (nodes other than the receiving node) is received, the data confirmation can be sent to the client, and the client The data confirmation confirms that the messages stored by the nodes are consistent, and it is not necessary to continue to switch to the second consensus mode. Therefore, the process of returning the notification of the first consensus mode and the process of switching to the second consensus mode may be sent to each node of the distributed system. termination.
  • the hash value sent by node 1 to node 2 to node N the hash value carries the digital signature of node 1, and after node 2 to node N-1 succeed in verifying the digital signature of node 1, node 2 is taken as an example, the node 2
  • the hash value of the message stored persistently by node 2 (for the node in the blockchain system, the hash value of the latest block in the blockchain) is compared with the hash value sent by node 1. If it is consistent, it sends a data confirmation to node 1, and the processing for node 3 to node N-1 is similar to that of node 2.
  • node 1 receives the data confirmation from node 2 to node N-1, but does not receive the data confirmation of node N. Since the client does not receive the data confirmation of node 1 within the predetermined time, the client considers that node 1 has not obtained If the data of all other nodes are consistent, the node 1 to node N are notified to continue the operation of switching to the second consensus mode.
  • the hash value sent by node 1 to node 2 to node N the hash value carries the digital signature of node 1, and after node 2 to node N-1 succeed in verifying the digital signature of node 1, node 2 is taken as an example, the node 2
  • the hash value of the message stored persistently by node 2 (for the node in the blockchain system, the hash value of the latest block in the blockchain) is compared with the hash value sent by node 1. If it is consistent, it sends a data confirmation to node 1, and the processing for node 3 to node N-1 is similar to that of node 2.
  • the node 1 receives the data confirmation of the node 2 to the node N-1 within a predetermined time, but does not receive the data confirmation of the node N, and sends a notification to the client that the other node data confirmation is not completely received within the predetermined time, the client The terminal notifies the node 1 to the node N to continue the operation of switching to the second consensus mode.
  • the hash value sent by the node 1 to the node 2 to the node N the hash value carries the digital signature of the node 1, and after the node 2 to the node N-1 succeed in verifying the digital signature of the node 1, the node 2 is taken as an example.
  • the hash value of the message that node 2 persists stored by node 2 may be the hash value of the latest block in the blockchain) and the hash value sent by node 1
  • the comparison if consistent, sends a data acknowledgment to node 1, and the processing for node 3 to node N-1 is similar to node 2.
  • node 1 Assuming that node 1 receives the data acknowledgment from node 2 to node N-1 within a predetermined time, but does not receive the data acknowledgment of node N, node 1 sends to the client that all other nodes are not received (that is, in the distributed system) The notification of the data confirmation of the node other than the node 1 informs the node 1 to the node N to continue the operation of switching to the second consensus mode.
  • Method 1 When the number of times the master node reaches the consensus formation exceeds the threshold number of the consensus of the master node, the slave node is triggered to switch back to the first consensus mode, and the master node and the slave node inherit the second consensus mode when switching to the first consensus mode.
  • the state of the node that is, the state of the node as the primary or secondary node remains unchanged.
  • the master node When the distributed system is in the second consensus mode, for the master node in the distributed system (understandably, the master node here is for a consensus cycle), if the master node counts in the second consensus mode The number of times the slave node reaches consensus on the received message exceeds the threshold of the master node consensus number (eg, M times, M is set according to the accuracy of the consensus on the nodes in the distributed system. Generally, the higher the accuracy requirement, the more the predetermined number of times Large, the two have a positive correlation relationship), indicating that the master node and the slave node have reached a good consensus for the continuous message from the client. In order to further improve the efficiency of the consensus of the nodes of the distributed system, it is possible to switch to the slave node to Notification of the first consensus model.
  • M times M is set according to the accuracy of the consensus on the nodes in the distributed system.
  • the handover confirmation is sent to the master node (acknowledging that the master node can continue to maintain the master when switching to the first consensus mode)
  • the state of the node the master node and the slave node switch to the first consensus mode to maintain the state of the current node, so that in the first consensus mode, the malicious node can be prevented from becoming the master node, and the efficiency of the consensus is ensured.
  • consensus node number threshold may be the number of all slave nodes in the distributed system, or the minimum number of slave nodes in the distributed system that require consensus in the first consensus mode (ie, the first The minimum number of consensus nodes required for the fault-tolerant performance of the consensus mode, below which the reliability of the consensus reached in the first consensus mode cannot be guaranteed).
  • the above-mentioned consensus node ratio threshold may correspond to the number of all slave nodes in the distributed system, that is, 100%, or the minimum value of the number of slave nodes in the distributed system that require consensus in the first consensus mode. 51% (that is, the minimum number of consensus nodes required for fault tolerance performance of the first consensus mode, below which the reliability of the consensus reached in the first consensus mode cannot be guaranteed).
  • the distributed system assumes that node 1 is the master node, node 2 to node N are slave nodes, and each node counts the consensus reached by the client from the message. For node 1, if node 1 The node 2 to the node N have reached a consensus on the M (primary node consensus number threshold) messages from the client recently, indicating that a good consensus has been reached between the nodes, and the node 1 broadcasts to the node 2 to the node N to switch to the first In a notification of the consensus mode, the node 2 to the node N send a handover confirmation to the node 1, acknowledging that the node 1 is still the master node in the first consensus mode, and the node 2 to the node 2N continue to act as the slave node even if the node 2 to the node N appear A malicious node cannot falsify messages from the client to ensure the efficiency of the node's consensus.
  • the master node counts the number of times the consensus is formed exceeds the threshold number of the consensus of the master node, and the master node triggers the slave node to switch back to the first consensus mode.
  • the slave node statistics reach the threshold for forming the consensus number exceeds the consensus threshold number of the slave node, the slave node confirms Switching back to the first consensus mode, the master node and the slave node inherit the node state in the second consensus mode when switching to the first consensus mode (ie, the state of the node as the master node or the slave node remains unchanged).
  • the master node When the distributed system is in the second consensus mode, the master node counts the number of times that the other nodes (including the master node and other slave nodes) form a consensus with the message from the client in the second consensus mode, if the number of consensus formations exceeds the slave node
  • the consensus number threshold (which may be less than or equal to the master node consensus number threshold, for example, may be M/2), sends a notification to the master node that the master node continues to be the master node in the first consensus mode, in the second consensus mode
  • the slave node continues as the slave node when switching to the first consensus mode, thereby completing the election operation to switch to the first consensus mode, and continues to reach a consensus on the message from the client in the first consensus mode. In this way, in the first consensus mode, the situation that the malicious node becomes the master node can be avoided, and the efficiency of the consensus is ensured.
  • the node of the distributed system switches to the first consensus mode, if no abnormal node is detected in the first consensus mode, the mode remains unchanged in the first consensus mode, and if the first consensus mode is returned, the better is still not obtained. Consensus (for example, still detecting a malicious node, an abnormal node, or an error node), then switching back to the second consensus mode.
  • the master node of the distributed system may start timing based on the counter after switching to the second consensus mode, and after the timing time reaches the timing threshold (eg, 10 minutes), the slave node of the distributed system may be triggered to synchronously switch back to the first.
  • Consensus mode performing an election operation in the first consensus mode to determine a new master node and a slave node; if an abnormal node is still detected after switching to the first consensus mode, switching back to the second consensus mode again (switching to the first consensus)
  • the mode can be understood according to the foregoing description. Therefore, under the premise of using the second consensus mode to achieve consensus to ensure the fault tolerance performance of the distributed system, the efficiency of the consensus of the distributed system is maximized.
  • node 1 is the master node
  • node 2 to node N are slave nodes
  • each node counts the consensus reached by the client from the message.
  • node 1 if node 1 The node 2 to the node N have reached a consensus on the M (primary node consensus number threshold) messages from the client recently, indicating that a good consensus has been reached between the nodes, and the node 1 broadcasts to the node 2 to the node N to switch to the first
  • node 2 is taken as an example, node 2 counts the number of times of consensus formation in the second consensus mode, and if M/2 is exceeded, a handover confirmation is sent to node 1 (confirmation Node 1 still acts as the master node when switching to the first consensus mode, node 2 acts as the slave node; the processing of node 3 to node N is similar to that of node 2, and the description will not be repeated.
  • the node 1 When the node 1 receives the handover confirmation sent by each of the nodes 2 to N, switches to the first consensus mode and in the first consensus mode, the node 1 serves as the master node, and the node 2 to the node N serve as the slave nodes; Node 1 does not receive the handover confirmation sent by each node from node 2 to node N, and then stays in the second consensus mode. Each interval M/2 times the consensus node 1 continues to send to node 2 to node N and switches to the first consensus. The notification of the mode until the handover confirmation of all nodes of node 2 to node N is received.
  • the blockchain system (such as maintaining a federated chain system open to individual individuals or entities) adopts the improved RAFT (T-RAFT) algorithm in the first consensus mode and the PBFT algorithm in the second consensus mode.
  • T-RAFT improved RAFT
  • the Paxos algorithm can also be used in the first consensus mode
  • the BFT algorithm, BFT-RAFT, etc. can also be used in the second consensus mode
  • the first consensus mode can adopt any consensus efficiency and can detect node failure or Byzantine node algorithms such as the T-RAFT algorithm
  • the second consensus mode can employ any algorithm that can achieve Byzantine fault tolerance.
  • the RAFT algorithm provided by the related technology only solves the problem of data consistency of multiple nodes, and does not solve Byzantine fault tolerance, but the RAFT algorithm is relatively efficient.
  • the PBFT algorithm can solve Byzantine fault tolerance, but because of the need to broadcast messages in nodes in the PBFT algorithm, the implementation efficiency is relatively low.
  • the blockchain system has no node failure and no Byzantine node problem for most of the time.
  • the RAFT algorithm can efficiently achieve consensus between nodes.
  • the related technology provides RAFT to solve the problem of multiple node consistency, the efficiency is relatively high, but the problem of Byzantine fault tolerance between nodes is not solved, and the PBFT algorithm can ensure the consistency of multiple nodes and solve the Byzantine fault tolerance between nodes. Therefore, in the embodiment of the present invention, as long as there is a node error or a Byzantine problem, the PBFT algorithm can be automatically adopted to implement the consensus of each node. When all the nodes reach a consensus, that is, there is no Byzantine node, then automatically switch to A consensus-efficient RAFT algorithm implements consensus among nodes.
  • FIG. 8 is an optional flowchart diagram of the blockchain system according to the embodiment of the present invention adopting the RAFT algorithm to reach a consensus.
  • the master node sorts the received message. Is distributed to the slave nodes (follower nodes) according to the sort. The other followers store the messages in the log according to the order in which the leader nodes are organized, and return the RPC result (result) to the leader node, and then the leader node stores the messages in the log on the local disk.
  • a commit is sent to each slave node, and each slave node stores the log in the message on the local disk of the slave node, and the message synchronization consistency is completed, which has high efficiency, but cannot solve Byzantium. Node problem.
  • FIG. 9 is an optional flow diagram of a blockchain system according to an embodiment of the present invention using a PBFT algorithm to achieve consensus.
  • a message needs to be broadcast twice before it can be truly confirmed.
  • the number of messages sent is the square of the number of nodes, so the efficiency of achieving consensus is relatively low, but it can solve the problem of Byzantine fault tolerance between nodes.
  • the RAFT algorithm can solve the consistency problem and is efficient, but can not solve the Byzantine fault tolerance problem, it is not adopted in many blockchain system scenarios, but can only adopt the relatively inefficient PBFT algorithm that can solve Byzantine fault tolerance.
  • the embodiments of the present invention fully utilize the characteristics of the application scenario in the alliance chain: in most cases, the network conditions are good and there is no Byzantine node, and only a consensus is required between multiple nodes, and the efficiency of RAFT and the fault tolerance of PBFT are combined to provide high efficiency and An adaptive consensus algorithm for solving the Byzantine fault tolerance problem.
  • the number of nodes participating in the consensus is limited, and in most cases, each participating node does not have a Byzantine node, and only needs to ensure data consistency.
  • a more efficient T- is adopted.
  • RAFT algorithm When an abnormality occurs, such as a Byzantine fault tolerance requirement or a node failure between nodes, it can be detected in time and can automatically switch to a PBFT algorithm that can support Byzantine fault tolerance. When all nodes in the PBFT algorithm reach a consensus, they automatically switch to efficiency.
  • the higher T-RAFT algorithm in the vast majority of cases, when the network is good and there is no Byzantine node, it can meet the requirements of the efficient consensus of the alliance chain. When there are abnormal nodes, it can be corrected and fault-tolerant in real time.
  • FIG. 10 is a schematic diagram of the implementation of the adaptive consensus algorithm according to an embodiment of the present invention.
  • the blockchain system defaults to the T-RAFT algorithm, and the T-RAFT algorithm detects the data.
  • the confirmation status of the data (message) consistency is entered: if the data of each node is confirmed to be consistent, Go back to the T-RAFT algorithm: if the data of the nodes is inconsistent, switch to the PBFT algorithm to achieve the consensus between the nodes.
  • the PBFT algorithm is running, it detects that the data of all nodes is consistent, and then switches to the T-RAFT algorithm.
  • the T-RAFT algorithm is an improvement of the RAFT algorithm, which can prevent the node from tampering, replaying, forging the message, and can detect the malicious node in time.
  • FIG. 11 is a schematic diagram of the implementation of the T-RAFT algorithm consensus provided by the embodiment of the present invention. Compared with the RAFT algorithm, the improvements involved mainly involve the following aspects:
  • the message sent by the client has a digital signature for the message body of the message, so that the message can be prevented from being modified during the transmission process, and the message carries the uniqueness field, which can prevent the message from being intercepted and then played back. .
  • the message transmitted between each node carries the digital signature of the sender, and the receiving node of the message verifies the correctness of the digital signature, which can prevent the forged new node from participating in the election operation or pretending that the master node sends a false message to the slave node. .
  • the master node message in the T-RAFT consensus mode is synchronized to the slave node, and all the slave nodes receive the message sent by the master node, except for completing the original RAFT message flow. , will return the result to the client, returning the uniqueness field in the message with the digital signature of the slave node.
  • the client can judge the consistency of the data (message) of each node by comparing the results returned by all nodes and whether they are consistent. If the result received by the client is inconsistent or the result of all nodes is not received within the predetermined time, it is judged that there is a Byzantine node or a faulty node, and the process of data consistency confirmation is triggered.
  • the process of data consistency confirmation occurs in the middle stage of consensus algorithm switching.
  • the process of data repair is actually a minority consensus process that is subject to majority.
  • the process of consensus uses message broadcast. Specifically, the node uses T-RAFT algorithm by default. When there is a node error or a Byzantine node, the client can find out the inconsistency of the data by comparing the results returned by each node to determine whether the algorithm needs to be switched.
  • the client broadcasts to the nodes to notify all nodes of the PBFT algorithm, and when the node receives the notification of the consensus algorithm switch and is in the Prepare phase, broadcast data.
  • the data request confirmation message carries the hash value of the nearest consensus block in the node's blockchain and the digital signature of the node
  • the node that receives the data request confirmation message referred to herein as the receiving node, checks whether the hash value of the latest consensus block in the blockchain of the node is consistent with the hash value carried in the data request confirmation message, and verifies the node number.
  • the correctness of the signature for the receiving node, if the data request confirmation message of all other nodes is received, and the data request confirmation message signature is correct, and the hash value of the block with the latest consensus of the receiving node is consistent, the customer is replied to End data consistency confirmation, which carries the digital signature of the receiving node.
  • the client receives the data consistency confirmation of all nodes, it is considered that the data of the blockchain maintained by each node is consistent, and the data consistency comparison failure before the algorithm switching request is considered to be caused by network fluctuation or discard response message. , will switch back to the T-RAFT algorithm.
  • the specific process can refer to the following message flow chart:
  • FIG. 12 is an optional schematic flowchart of switching back to the T-RAFT algorithm in the preparation phase of PBFT algorithm switching according to an embodiment of the present invention.
  • nodes 1, 2, and 3 are shown. 4, all received broadcast messages from other nodes for data consistency confirmation, and confirmed that the hash values of the latest consensus blocks of each node are also consistent, each node returns a data consistency confirmation to the client, and each returns T- The state of the RAFT algorithm, even if the client does not reach the node by re-switching to the T-RAFT notification, the node will enter the election process of the T-RAFT algorithm after the timeout period has elapsed.
  • the broadcast of the consistency confirmation of all other nodes is not received.
  • the client notifies all nodes to switch to the PBFT algorithm.
  • the PBFT algorithm state is automatically entered, and the notification of switching to the PBFT algorithm is broadcasted.
  • f is the maximum value of the erroneous nodes that can be allowed in the blockchain system according to the PBFT algorithm
  • PBFT master node in the new algorithm
  • FIG. 13 is an optional schematic flowchart of a blockchain system switching from a T-RAFT algorithm consensus to a PBFT algorithm consensus according to an embodiment of the present invention.
  • node 4 is faulty
  • node 1 is When 2 and 3 receive the notification of the switching algorithm of the client and are in the handover preparation phase of the PBFT algorithm, respectively, the data request confirmation message is broadcasted, and the hash value of the block block of the latest consensus is received in the message, and the node 4 is faulty.
  • Nodes 1, 2, and 3 will not receive the data consistency confirmation (consistent response) broadcast by Node 4 within the timeout period, so no data consistency confirmation will be sent to the client, and nodes 1, 2, 3, and the client are timed out.
  • the switch to the PBFT algorithm is broadcasted, and the nodes 1, 2, and 3 receive the notification of the algorithm switch.
  • the node that receives the f+1 algorithm switch notification first initiates the view change process. After the replacement is completed, enter the PBFT algorithm consensus mode.
  • the master node In the consensus of PBFT, once the master node counts that the data (continuously appearing M times (configurable) is consistent, it will be converted into a T-RAFT competing node and trigger the T-RAFT election process. After other nodes receive the election request, As long as the number of consecutive consensuses is also greater than M/2 times or greater than a fixed configuration value T, the competing node is converted to be the master node. Only when all the slave nodes agree that the competing node is converted to the master node, enter T-RAFT. The consensus mode of the algorithm, the number of consecutive consensus times of each node will be cleared.
  • the competing node immediately restores the original state to the master node of the PBFT algorithm, and continues to execute the PBFT algorithm.
  • the consensus statistics of each node continue to accumulate until M+T When the T-RAFT election is triggered again, if it is not successful, the next time it is triggered by M+2T, so reciprocating, M+x*T is triggered at the moment, and x is the number of times until the election of the master node is successful.
  • FIG. 14 is an optional schematic flowchart of the PBFT algorithm consensus mode switching to the T-RAFT algorithm consensus mode according to the embodiment of the present invention.
  • the master node is the node 1 statistics. When the data is consistent (consensus) more than M times, it is converted to the T-RAFT's competing node state, and then the T-RAFT algorithm is elected. After nodes 2, 3, and 4 receive the request vote message, it is judged whether It is also counted that the number of consecutive data matches is greater than M/2 (or a fixed value T), and if so, a switch confirmation that agrees that the contention node is converted to the master node is returned.
  • M/2 or a fixed value T
  • the competing node receives the handover confirmation of the 2, 3, and 4 nodes, and converts to the master node to start the T-RAFT algorithm consensus phase.
  • the primary node (node 1) in the original PBFT consensus mode does not send a sequence message after receiving the message from the client, such as a PRE-PREPARE message in the PBFT algorithm, waiting for the election. Completed, the message is attached to the slave node in the AppendEntries RPC in T-RAFT.
  • FIG. 15 is a schematic diagram of an optional scenario in which a distributed system is applied to an alliance chain system according to an embodiment of the present invention.
  • the alliance chain system is a separate entity or entity. Open, including multiple nodes, each node provides access to a third-party payment institution, and a banking system (as a client), receives a transaction record submitted by a third-party payment institution, and a banking system, and the node submits one After the transaction record forms a consensus, the transaction record will be stored in the latest block of the blockchain for the third-party payment institution and the contracted bank to reconcile according to their respective business flows.
  • the node uses the T-RAFT consensus mode to obtain a consensus on transaction records.
  • the node switches to the PBFT consensus mode to gain consensus on transaction records.
  • the third-party payment terminal may pre-authorize the credit card account from the user's credit card account. Transfer money to the merchant's account to form a transaction record.
  • the third party payment institution's business system submits a transaction record (eg, including the payee, payer, and payment amount) to the primary node accessed in the distributed system, carrying the third party payment client.
  • Digital signature After receiving the transaction record verification digital signature successfully, the master node synchronizes the transaction record to other slave nodes (carrying the digital signature of the master node), and after verifying the digital signature of the transaction record from the node, on the other hand,
  • the result returned by the three-party payment institution business system (carrying the digital signature of the slave node, the uniqueness field, and carrying the serial number of the transaction record when the master node is the newly elected master node); on the other hand, notifying the master node that the synchronization is completed;
  • the node After confirming that each slave node is synchronized, the node stores the transaction record in the latest block of the blockchain and notifies each slave node, and the slave node performs the same operation to complete the persistent storage of the transaction record.
  • the alliance chain system is triggered to switch to the PBFT consensus mode to obtain a consensus on the transaction record, ensuring Transaction records can be stored smoothly in the blockchain of each node; according to the consensus of the alliance chain system on the transaction records submitted by the third-party payment structure business system, such as obtaining a better formula (the master node and other nodes continue M consensus) ), you can switch back to the T-RAFT consensus mode to improve the efficiency of the consensus.
  • the digital signature is used between the client and the node to ensure the reliability of the communication, avoid the situation of message masquerading, and ensure the reliability of the internal communication of the distributed system.
  • the slave node When the slave node receives the message sent by the master node, it directly returns the result to the client, and carries the necessary information such as the uniqueness field, the message sequence number and the digital signature in the result, so that the client can directly refer to the slave node. As a result of the return, it is determined that the node has reached a consensus, and the abnormal node can be easily detected.
  • the foregoing storage medium includes: a mobile storage communication state processing device, a random access memory (RAM), a read-only memory (ROM), a magnetic disk or an optical disk. And other media that can store program code.
  • the above-described integrated unit of the present invention may be stored in a computer readable storage medium if it is implemented in the form of a software function module and sold or used as a standalone product.
  • the technical solution of the embodiments of the present invention may be embodied in the form of a software product in essence or in the form of a software product, which is stored in a storage medium and includes a plurality of instructions for making
  • a computer communication state processing device (which may be a personal computer, server, or network communication state processing device, etc.) performs all or part of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a mobile storage communication state processing device, a RAM, a ROM, a magnetic disk, or an optical disk, and the like, which can store program codes.

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)
  • Bioethics (AREA)
  • General Health & Medical Sciences (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)采用数字签名的方式保证分布式系统中通信的可靠性：对于任意通信的双方均采用数字签名的方式，即在发送消息时会携带消息的数字签名，通过验证数字签名确保接收消息的可靠性。
2)从节点在接收主节点发送的消息时，会直接向客户端返回结果，在结果中携带必要的信息如唯一性字段、消息序列号和数字签名等，从而，客户端可以直接根据从节点返回的结果来判定从节点达成共识的情况高效检测出异常节点。
附图说明
图1是本发明实施例提供的分布式系统100应用于区块链系统的一个可选的结构示意图；
图2是本发明实施例提供的区块结构一个可选的示意图；
图3A是本发明实施例提供的节点200的一个可选的软硬件结构示意图；
图3B是本发明实施例提供的客户端300的一个可选的软硬件结构示意图；
图4是本发明实施例提供的在第一共识模式中各节点执行选举操作而确定主节点和从节点的一个可选的示意图；
图5是本发明实施例提供的分布式系统的节点在第一共识模式中达成共识、并检测故障节点和恶意节点的一个可选的流程示意图；
图6是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图；
图7是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图；
图8是发明实施例提供的区块链系统采用RAFT算法达成共识的一个可选的流程示意图；
图9是发明实施例提供的区块链系统采用PBFT算法达成共识的一个可选的流程示意图；
图10是本发明实施例提供的实现自适应共识算法运行状态图；
图11是本发明实施例提供的T-RAFT算法共识的实现示意图；
图12是本发明实施例提供的在PBFT算法切换的准备阶段进行切换回T-RAFT算法的一个可选的流程示意图；
图13是本发明实施例提供的区块链系统从T-RAFT算法共识切换到PBFT算法共识的一个可选的流程示意图；
图14是本发明实施例提供的区块链系统PBFT算法共识模式切换到T-RAFT算法共识模式的一个可选的流程示意图；
图15是本发明实施例提供的分布式系统应用于联盟链系统的一个可选的场景示意图。
具体实施方式
以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本发明，并不用于限定本发明。另外，在不冲突的情况下，本发明实施例记载的技术方案可以任意组合的方式实施。
1)分布式系统，由多个节点和客户端之间通过网络通信而连接形成的系统，网络通信所使用的消息的内容根据实际的业务场景而有区别，例如，消息可以为交易记录、供节点的状态机执行的指令等。
2)共识，在分布式系统中，节点对其他节点(即，分布式系统中除发 送消息的节点的任意节点)发送的消息的正确性进行验证，如验证成功则向发送消息的节点发送确认，并将该消息进行持久化存储，以用于支持后续进行查询。
例如，在分布式系统实施为区块链系统时，节点对其他节点提交的新区块(包括新产生的交易记录)的有效性进行验证，如验证成功则向发送新区块的节点发送确认，并将该新区块添加到相应节点所存储的区块链的尾部，以完成区块链中交易记录的共识。
3)共识模式，也称为共识算法，用于保证分布式系统的节点达成共识的算法，共识模式可以包括以下的类型：
第一共识模式，能够实现较高的共识效率、并且能够检测到节点故障或者拜占庭问题(一方向另一方发送消息，另一方没有收到，或者收到了错误的信息的情况)、但是无法解决拜占庭问题的共识模式，示例性地，实现第一共识模式的算法包括Paxos算法和递归容错算法(RAFT，Recursive Algorithm for Fault Tolerance)。
第二共识模式，用于解决拜占庭问题的共识模式，实现第二共识模式的算法包括：拜占庭容错(BFT，Byzantine Fault Tolerance)算法、实用拜占庭容错(PBFT，Practical Byzantine Fault Tolerance)算法、递归容错算法-拜占庭容错(BFT-RAFT，Byzantine Fault Tolerance Recursive Algorithm for Fault Tolerance)、拜占庭容错(BFT-Paxos)算法等。
4)共识模式切换，也称为共识模式自适应，分布式网络使用的共识算法在网络环境良好的时候自动采用共识效率高可以检测到异常节点(如拜占庭问题的节点)的算法以实现第一共识模式，当发现恶意节点或者节点错误的时候，自动切换到以支持解决拜占庭容错的算法以实现第二共识模式。
实现本发明实施例的分布式系统由客户端、多个节点(接入网络中的 任意形式的计算设备，如服务器、用户终端)通过网络通信的形式连接形成，下面对客户端和节点的功能进行说明。
节点，配置为当第一共识模式中新的共识周期到达时，通过执行选举操作确定处于主节点的状态或处于从节点的状态；
节点，配置为当处于主节点的状态时，验证客户端发送的消息的数字签名，将消息发送到从节点；
节点，配置为当处于主节点的状态时，接收到超出预定数量的从节点的确认接收通知，验证确认接收通知的数字签名后持久化存储消息，向从节点发送存储消息通知；
节点，还配置为当处于从节点的状态时，接收到主节点发送的消息时向客户端返回结果，验证从主节点所接收的消息的数字签名，向主节点发送确认接收通知；
节点，配置为当处于从节点的状态时，验证从主节点所接收的存储消息通知的数字签名，持久化存储从主节点所接收的消息；
客户端，配置为根据从节点接收到消息时返回的结果，确定分布式系统中的异常节点。
在一个实施例中，客户端还配置为验证所接收结果的数字签名后，将所接收结果包括的唯一性字段与所发送消息的唯一性字段比较，确定不一致的唯一性字段对应的从节点为出错节点，确定未返回结果的从节点为故障节点。
在一个实施例中，客户端还配置为根据所接收结果携带的序列号与所发送消息的序列号比较，当发送不一致序列号的从节点的数量超出不一致数量阈值时，判定主节点为恶意节点。
在一个实施例中，客户端还配置为确定主节点为恶意节点，或者，确定从节点中存在故障节点时，触发分布式系统中节点切换到第二共识模式。
在一个实施例中，节点还配置为当处于切换到第二共识模式的准备阶段时，将节点持久化存储的消息的哈希值，与分布式系统中节点持久化存储的消息的哈希值比较，确认一致时向客户端发送一致性确认，一致性确认携带相应节点的数字签名；
客户端还配置为在预定时间内接收到全部节点的一致性确认时，通知分布式系统中节点返回第一共识模式，未在预定时间内接收到全部节点的一致性确认时，通知分布式系统中节点继续切换到第二共识模式。
在一个实施例中，节点还配置为当处于切换到第二共识模式的准备阶段时，将节点持久化存储的消息的哈希值，与分布式系统中节点持久化存储的消息的哈希值比较，确认一致时向消息的发送节点发送数据确认，数据确认携带相应节点的数字签名；
客户端，还配置为在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时，或在预定时间内分布式系统中节点未接收到数据确认时，触发分布式系统中节点继续切换到第二共识模式。
在一个实施例中，节点还配置为当处于主节点的状态，并在第二共识模式中统计到的的次数超过主节点共识次数阈值时，与从节点切换到第一共识模式，其中，所统计到的次数为与从节点针对所接收的消息形成共识的计数。
在一个实施例中，节点还配置为当处于主节点的状态时，并在所统计到的次数超过主节点共识次数阈值时，向从节点发送切换到第一共识模式的通知，并在接收到全部从节点发送的切换确认时，与从节点开始同步切换到第一共识模式。
在一个实施例中，节点还配置为当处于从节点的状态，接收到切换到第一共识模式的通知，且统计到针对所接收的消息形成共识的次数超过从节点共识次数阈值时，向主节点发送切换确认。
在一个实施例中，节点还配置为未接收到主节点的心跳信息时，或者，主节点为恶意节点时，通过重新执行选举操作确定处于主节点的状态或处于从节点的状态。
在一个实施例中，节点还配置为在新的共识周期到达、且未接收到任意节点发送的心跳信息时，向分布式系统中节点发送选举请求，当接收预定数量的节点返回的选举确认时，转换为主节点的状态并定期向分布式系统中节点发送心跳信息；
其中，选举确认为分布式系统中节点发送，且在发送之前验证选取请求携带的数字签名；
在一个实施例中，节点还配置为在新的共识周期到达、且接收到分布式系统中节点发送的心跳信息时，转换为从节点的状态。
下面，以分布式系统实施为区块链系统为例说明，参见图1，图1是本发明实施例提供的分布式系统100实施为区块链系统的一个可选的结构示意图，由多个节点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)一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。
实现本发明实施例的分布式系统的构成具有可灵活变动的特点，举例来说，在分布式系统中，任何机器如服务器、终端都可以加入分布式系统而成为节点，在硬件层面上，示例性地，参见图3A，图3A是本发明实施 例提供的节点200的一个可选的软硬件结构示意图，节点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(配置为在第一共识模式和第二共识模式中自适应切换)、以及节点基于分布式系统实现 的功能如电子货币钱包280、智能合约290等，包括第一共识模式和第二共识模式。
就应用层举例来说，参见图3A，图3A提供的节点200的应用层的共识机制270包括：
选举单元2701，配置为在第一共识模式中新的共识周期到达时，节点200分布式系统中的其他节点通过执行选举操作处于主节点的状态或处于从节点的状态；
主节点单元2702，配置为当节点200处于主节点的状态时，接收客户端的消息，验证消息的数字签名后将消息发送到从节点；以及，接收到超出预定数量的从节点的确认接收通知时，验证确认接收消息的数字签名后持久化存储消息，向从节点发送存储消息通知；
其中，从节点接收到所述消息时返回的结果，用于供所述客户端确定所述分布式系统中的异常节点。
从节点单元2703，配置为当节点200处于从节点的状态时，验证所接收的存储消息通知的数字签名后持久化存储所接收的消息；消息用于供客户端确定异常节点；
在一个实施例中，从节点单元2703，配置为当节点200处于从节点的状态时，执行以下操作：接收到主节点发送的消息并向客户端返回结果，验证所接收的消息的数字签名后向主节点发送确认接收通知，以及，验证所接收的存储消息通知的数字签名后持久化存储所接收的消息。
在一个实施例中，当节点200处于从节点的状态时，从节点向客户端返回结果携带以下信息：消息的唯一性字段，从节点的数字签名；结果用于供所述客户端验证携带的数字签名，将结果包括的唯一性字段与所发送消息的唯一性字段比较，确定不一致的唯一性字段对应的从节点为出错节点，以及确定未返回相应结果的从节点为故障节点。
在一个实施例中，当节点200处于从节点的状态时，从节点所返回的结果携带从节点所接收消息的序列号，结果携带的序列号用于供客户端将所接收结果携带的序列号与所发送消息的序列号比较，当发送不一致序列号的从节点的数量超出不一致数量阈值时，判定主节点为恶意节点。
在一个实施例中，还包括切换单元2704，配置为当客户端确定主节点为恶意节点，或者，确定从节点中存在故障节点时，响应于客户端的触发而切换到第二共识模式。
在一个实施例中，切换单元2704，还配置为当节点200处于切换到第二共识模式的准备阶段时执行以下操作：
将节点200持久化存储的消息的哈希值，与分布式系统中节点(即，分布式系统中除节点200的节点)持久化存储的消息的哈希值比较，确认一致时向客户端发送一致性确认，一致性确认携带相应节点的数字签名，用于供客户端接收到一致性确认时进行验证；
当客户端在预定时间内接收到全部节点的一致性确认时，响应于客户端的通知切换到第一共识模式；
当客户端未在预定时间内接收到全部节点的一致性确认时，响应于客户端的通知继续切换到第二共识模式。
在一个实施例中，切换单元2704，还配置为当节点200处于切换到第二共识模式的准备阶段时，执行以下操作：
将节点持久化存储的消息的哈希值与分布式系统中节点(即，分布式系统中除节点200的节点)持久化存储的消息的哈希值比较，确认一致时向消息的发送节点发送数据确认，数据确认携带相应节点的数字签名；
其中，数据确认，配置为供客户端在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时，或在预定时间内分布式系统中节点未接收到其他节点发送的数据确认时，触发分布式系统的节点继续切换到 第二共识模式。
在一个实施例中，主节点单元2702，还配置为当节点200处于主节点的状态，并在第二共识模式中统计到与从节点针对所接收的消息形成共识的次数超过主节点共识次数阈值时，与从节点切换到第一共识模式。
在一个实施例中，主节点单元2702，还配置为在第二共识模式中统计到的次数超过主节点共识次数阈值时，向从节点发送切换到第一共识模式的通知，并在接收到全部从节点发送的切换确认时，与从节点开始同步切换到第一共识模式；其中，所统计到的次数为与从节点针对所接收的消息形成共识的计数。
在一个实施例中，从节点单元2703，还配置为当节点处于从节点的状态时执行以下操作：当接收到切换到第一共识模式的通知时，统计针对所接收的消息形成共识的次数，当所统计到的次数超过从节点共识次数阈值时，向主节点发送切换确认。
在一个实施例中，选举单元2701，还配置为当未接收到主节点的心跳信息时，或者，主节点为恶意节点时，与分布式系统中节点(即，除分布式系统中除节点200的节点)通过执行选举操作确定处于主节点的状态或处于从节点的状态。
在一个实施例中，选举单元2701，还配置为当在新的共识周期到达、且未接收到分布式系统中节点发送的心跳信息时，向分布式系统中节点发送选举请求，选举请求携带节点的数字签名；当接收预定数量的节点返回的选举确认时，转换为主节点的状态，定期向分布式系统中节点发送心跳信息以保持主节点的状态；其中，选举确认为分布式系统中节点验证选取请求携带的数字签名后发送；
选举单元2701，还配置为当在新的共识周期到达、且接收到分布式系统中节点发送的心跳信息时转换为从节点的状态。
在分布式系统中，客户端可以是硬件以及在硬件上部署的软件环境的结合，基于此，客户端也可以称为客户端设备，配置为实现挖矿、管理节点、部署智能合约等功能。
参见图3B，图3B是本发明实施例的客户端的一个可选的软硬件结构示意图，客户端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，还配置为在预定时间内接收到全部节点的一致性确认时，通知全部节点返回第一共识模式；未在预定时间内接收到全部节点的一致性确认时，通知全部节点继续切换到第二共识模式；
其中，所述一致性确认携带所述节点的数字签名，由所述节点处于切 换到所述第二共识模式的准备阶段时发送，且在发送前确定所述节点持久化存储的消息的哈希值、与所述分布式系统中节点持久化存储的消息的哈希值一致。
在一个实施例中，切换单元3703，还配置为在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时，或在预定时间内分布式系统中节点未接收到由其他节点发送的数据确认时，触发分布式系统中节点继续切换到第二共识模式；
其中，数据确认携带相应节点的数字签名，由节点200在处于切换到所述第二共识模式的准备阶段时发送，且在发送前确定节点200持久化存储的消息的哈希值、与分布式系统中节点(即，除分布式系统中除节点200的节点)持久化存储的消息的哈希值一致。
就本发明实施例提供的分布式系统来说，节点采用第一共识模式中对来自客户端的消息形成共识，第一共识模式能够保证节点形成共识的效率，当然，本发明实施例不排除分布式系统的节点默认采用第二共识模式对来自客户端的消息形成共识。
对在第一共识模式中达成共识的实现方式进行说明，参见图5，图5是本发明实施例提供的分布式系统的节点在第一共识模式中达成共识、并检测故障节点和恶意节点的一个可选的流程示意图，结合步骤101至步骤108进行说明。
步骤101，分布式系统的多个节点在第一共识模式中新的共识周期到达时，通过执行选举操作确定主节点的状态、以及处于从节点的状态。
在一个实施例中，分布式系统的节点具有三种类型(也称为状态)：竞争节点、主节点和从节点；分布式系统的各个节点启动计时器，在用于形成共识的新的共识周期到达时，各个节点均为竞争节点，各个竞争节点通过执行选取操作而争取转换为主节点(一个分布式系统只有一个合法的主 节点)，未成为主节点的竞争节点转换为从节点。
对于每个竞争节点，在新的共识周期开始时会检测是否接收到其他节点发送的心跳信息，如果没有接收到，说明当前共识周期内还未产生主节点，则该竞争节点向其他节点发送选举请求，在选取请求中携带发送节点的数字签名，接收节点验证选取请求的数字签名成功后，确定选举请求的可靠性，即向发送节点发送选举确认，当一个节点接收到足够(如预定数量可以为半数的节点)其他节点的选举确认时即转换为主节点，并定期向其他节点发送心跳信息，接收到心跳信息的竞争节点转换为从节点。当在一个共识周期内任意节点都没有接收的到足够数量的选举确认，则开始新的共识周期继续选取操作直至确定主节点和从节点。
以第一共识模式采用RAFT算法为例，参见图4，图4是本发明实施例提供的在第一共识模式中各节点执行选举操作而确定主节点和从节点的一个可选的示意图。
在分布式系统中，任何一个节点在任何一个时刻都处于三种状态中的一个状态：主节点、从节点和竞争节点；在分布式系统正常运行的绝大部分时间，分布式系统中会有一个主节点,其他节点都是从节点，由主节点接受客户端的消息。
分布式系统的工作时间分为连续的共识周期，这里也称为任期(Term)，每个任期可以是任意时长，任期用连续的整数进行标号。每个任期首先进行主节点选举，在选举阶段，多个竞争节点竞争成为主节点，一旦某个节点成为主节点，其他竞争节点则转变为从节点，成为主节点的节点将在该任期内一致担任主节点，如果该主节点发生故障，其他节点会在新的任期内进行选举。
任何一个任期内都不会有多个主节点(除非有恶意节点伪装为主节点)，每个节点都维护着当前任期的计数，每次节点间的之间的通信都包含 任期的计数，每个节点在检测到自己维护的任期计数低于其他节点维护的任期计数时，都会更新自己的任期计数为检测到的最高的值。
当前一共识周期的主节点和竞争节点发现自己的任期计数低于别的节点的任期计数时，则立即把自己转换为从节点，从而保证在每个任期内只有一个主节点。
RAFT算法中采用心跳机制触发主节点选举操作，当分布式系统启动时，所有节点初始化为从节点状态，设置任期为0，并启动计时器，计时器超时后，从节点转化为竞争节点，一旦转化为竞争节点，执行以下操作：
步骤1011，增加节点的任期的计数；
步骤1012，启动一个新的计时器；
步骤1013，向其他节点发送选取请求(Request Vote)远程过程调用协议(RPC，Remote Procedure Call Protocol)消息，并等待其他节点回复选举确认。
如果在计时器超时前接收到多数节点的选举确认，则转换为主节点。如果接受到其他节点发送的附加内容为空的附加入口(Append Entries)心跳RPC消息，说明其他节点已经被选为主节点,则转换为从节点。如果计时器超时还没有接受到以上两种信息中的任何一种，则进行新的选举操作。
节点在接受到多数节点的投票成为主节点后，会立即向所有节点发送Append Entries心跳RPC消息，竞争节点收到Append Entries心跳RPC消息后，转换为从节点，选举操作结束。
步骤102，客户端对消息进行数字签名，发送携带数字签名的消息给主节点。
客户端使用自身的私钥对消息的摘要(本发明实施例中不排除使用任意摘要算法从消息中提取摘要)加密，形成数字签名。
步骤103，主节点验证消息的数字签名成功后，在消息中添加主节点的 数字签名，将消息发送到从节点。
主节点使用公钥对数字签名解密得到摘要，与采用摘要算法(与客户端使用的摘要算法一致)进行比对，如果一致则说明消息的来源是可靠的，利用主节点的私钥对消息的摘要加密形成主节点的数字签名，在消息中添加主节点的数字签名发送到各个从节点。对于消息携带的客户端的数字签名可以携带也可以不携带；如果主节点比对不一致，可以丢弃消息并向客户端要求重传。
步骤104，从节点接收到主节点发送的消息后，验证接收的消息的数字签名，验证通过后向主节点发送确认接收通知，并向客户端发送结果。
从节点使用公钥对接收的消息的数字签名解密得到摘要，与采用摘要算法(与主节点使用的摘要算法一致)进行比对，如果一致则说明消息的来源是可靠的，利用从节点的私钥对确认接收通知的摘要加密形成从节点的数字签名，返回主节点。
从节点向客户端发送结果包括两种情况：
1)在当前共识周期内，如果从节点首次接收到主节点发送的消息，则向客户端发送的结果包括：所接收消息的序列号；消息的唯一性字段(消息中的字段，能够区别与其他消息的字段)；从节点针对结果的数字签名，利用从节点的私钥对结果的摘要进行加密得到。
2)在当前共识周期内，如果从节点非首次接收到主节点发送的消息，则向客户端发送的结果包括：消息的唯一性字段(消息中的字段，能够区别与其他消息的字段)；从节点针对结果的数字签名，利用从节点的私钥对结果的摘要进行加密得到。
步骤105，主节点验证接收到确认接收通知携带的数字签名，当连续接收到预定数量的从节点发送的确认接收通知后，持久化存储消息，向从节点发送存储消息通知。
存储消息通知中携带主节点针对存储消息通知的数字签名，数字签名为使用主节点的私钥对存储消息通知的摘要加密得到。
对于持久化存储而言，主节点将消息以非易失的方式存储，例如，在区块链系统中，接收到客户端提交的交易记录的节点(主节点)将交易记录存储在区块链的新区块中。
步骤106，从节点接收到存储消息通知，验证携带的数字签名成功后，在从节点本地持久化存储消息，并向主节点发送携带数字签名的存储消息确认。
从节点使用公钥对接收的存储消息通知的数字签名解密得到摘要，与采用摘要算法(与主节点使用的摘要算法一致)进行比对，如果一致则说明存储消息通知的来源是可靠的，利用从节点的私钥对存储消息确认的摘要加密形成从节点的数字签名，将携带数字签名的存储消息确认返回主节点。
步骤107，主节点对接收的存储消息确认的数字签名进行验证，如果接收到超过半数的从节点的存储消息确认并成功验证数字签名，向客户端发送存储消息确认。
主节点向客户端发送的存储消息确认中携带主节点的数字签名，用于供客户端验证存储消息来源的可靠性。
步骤108，客户端主节点和从节点接收到消息时返回的结果，检测异常节点：确定主节点是否为恶意节点，以及，确定从节点中是否存在故障节点。
在一个实施例中，客户端验证各个从节点返回的结果(各个从节点在接收到主节点发送的消息后发)的数字签名成功后，将所接收结果包括唯一性字段与所发送消息的唯一性字段比较，如果不一致，则判定发送不一致的唯一性字段的从节点为出错节点，对于没有返回结果的从节点则判定 为故障节点。
在一个实施例中，当主节点为在一个新的共识周期内新产生的主节点时，当接收该主节点发送的消息时，从节点向客户端发送的结果除了包括唯一性字段和数字签名，还包括所接收消息的序列号，从而，客户端能够根据所接收结果携带的序列号与所发送消息的序列号比较，当发送不一致序列号的从节点的数量超出数量阈值时，说明新产生的主节点向从节点发送了伪造的消息，因此判定主节点为恶意节点。
从上述步骤可以看出，在第一共识模式中：
1)采用数字签名的方式保证通信的可靠性：
对于任意通信的双方均采用数字签名的方式，即发送方在发送消息时会携带消息的数字签名例如，使用发送方的不对称加密算法的私钥对消息的摘要进行加密，形成发送方的数字签名，接收方通过验证数字签名确保消息的可靠性，即读消息的签名使用不对称加密算法的公钥(保证接收方和发送方使用相同的不对称加密算法，则接收方预先获知公钥)进行解密，对解密得到的摘要与从消息中提取的摘要比对，如果一致说明数字签名验证通过，发送方发送的消息是可靠的。
2)从节点在接收主节点发送的消息时，会直接向客户端返回结果，在结果中携带必要的信息如唯一性字段、消息序列号和数字签名等，这样，客户端可以直接根据从节点返回的结果来判定从节点达成共识的情况，能够容易地检测出异常节点。
在第一共识模式中检测到异常节点的情况，由于第一共识模式适用于保证节点的共识效率，而对节点异常的容错形能有限，为此，本发明实施例提供在分布式系统中出现异常节点时使分布式系统切换到具有较佳容错性能的第二共识模式的方案。
参见图6，图6是本发明实施例提供分布式系统在第一共识模式和第二 模式中进行切换的一个可选的流程示意图，结合步骤109至步骤112进行说明。
步骤109，客户端确定分布式系统中存在异常节点时，触发分布式系统中的节点从切换到第二共识模式。
当主节点为恶意节点、从节点中存在故障节点、或从节点中存在异常节点时，客户端向分布式系统的节点广播切换到第二共识模式的通知。
步骤110，分布式系统的节点在切换到第二共识模式的准备阶段中，向其他节点发送相应节点持久化存储的消息的哈希值以及数字签名。
以节点200为例，节点200在切换到第二共识模式的准备阶段中，向分布式系统中除节点200的节点发送节点200持久化存储的消息的哈希值以及数字签名。
步骤111，消息的接收节点接收到分布式系统中全部其他节点(即，除接收节点之外的全部节点)发送的哈希值以及数字签名，验证哈希值的数字签名成功后，将哈希值与接收节点持久化存储的消息的哈希值进行比较，如果全部一致，则向客户端发送一致性确认。
例如，分布式系统中接收到通知的节点1，在向第二共识模式切换的准备阶段，将节点中持久化存储的消息的哈希值以及数字签名发送(如广播)到节点2-N(N为分布式系统中节点的数量)，同时，节点1会接收节点2至节点N发送的哈希值，哈希值中携带相应节点的数字签名，节点1验证数字签名成功后，将节点2至节点N发送的哈希值与节点1持久化存储的消息的哈希值进行比较，如果全部一致，则节点1向客户端发送一致性确认。
对于节点2至节点N来讲，接收到哈希值的处理与节点1类似，不再重复说明。
步骤112，客户端检测是否接收到全部节点的一致性确认，如果是，则 通知分布式系统的节点继续切换到第一共识模式；如果否，则通知分布式系统的节点继续切换到第二共识模式。
如果客户端接收分布式系统中全部节点发送的一致性确认，说明之前检测到异常节点是由于网络波动或者丢弃响应消息导致的，分布式系统中不存在异常节点，因此重新切换到第一共识模式，保证节点之间达成共识的效率。
如果客户端没有在预定时间内接收分布式系统中全部节点发送的一致性确认，则说明分布式系统中确实存在异常节点，则通知分布式系统中节点继续保持向第二共识模式的切换。
参见图7，图7是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图，包括以下步骤：
步骤113，客户端确定分布式系统中存在异常节点时，触发分布式系统中的节点从切换到第二共识模式。
当主节点为恶意节点、从节点中存在故障节点、或从节点中存在异常节点时，客户端向分布式系统的节点广播切换到第二共识模式的通知。
步骤114，分布式系统的节点在切换到第二共识模式的准备阶段中，向其他节点发送相应节点持久化存储的消息的哈希值以及数字签名。
步骤115，消息的接收节点接收到分布式系统中其他节点发送的哈希值以及数字签名，验证哈希值的数字签名成功后，将哈希值与接收节点持久化存储的消息的哈希值进行比较，如果一致，则向消息的发送节点发送数据确认。
例如，分布式系统中接收到通知的节点1，在向第二共识模式切换的准备阶段，将节点中持久化存储的消息的哈希值以及数字签名发送(如广播)到节点2-N(N为分布式系统中节点的数量)，同时，节点1会接收节点2至节点N发送的哈希值，哈希值中携带相应节点的数字签名，节点1验证 数字签名成功后，将节点2至节点N发送的哈希值与节点1持久化存储的消息的哈希值进行比较，如果全部一致，则节点1向节点2至节点N分别发送数据确认。
对于节点2至节点N来讲，接收到哈希值的处理与节点1类似，不再重复说明。
步骤116，客户端根据各节点发送的数据确认触发分布式系统的节点返回第一共识模式，或，触发分布式系统的节点继续切换到第二共识模式。
对于分布式系统的各节点，将节点持久化存储的消息的哈希值以及发送节点的数字签名广播到其他节点；对于哈希值的接收节点来说，在验证所接收的哈希值的数字签名后，将所接收的哈希值的与接收节点存储消息的哈希值进行比较，在比较一致时向相应哈希值的发送节点发送数据确认，表示二个节点存储的消息是一致的。
这里涉及到两种情况：
情况1)在预定时间内，对于数据确认的接收节点来说，如果均接收到其他节点(除接收节点之外的节点)的发送的数据确认，则可以向客户端发送数据确认，客户端根据数据确认确认得知各节点存储的消息是一致的，没有必要继续切换到第二共识模式，因此可以向分布式系统的各节点发送返回第一共识模式的通知，向第二共识模式切换的过程终止。
例如，节点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)在预定时间内任意节点未接收到其他节点的数据确认时，或者，在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认，导致客户端未接收其他节点的数据确认，则客户端通知分布式系统中节点继续切换到第二共识模式。
例如，节点1向节点2至节点N发送的哈希值，哈希值携带节点1的数字签名，节点2至节点N-1在验证节点1的数字签名成功后，以节点2为例，节点2将节点2持久化存储的消息的哈希值(对于区块链系统中的节点来说，可以为区块链中的最新的区块的哈希值)与节点1发送的哈希值比较，如果一致则向节点1发送数据确认，对于节点3至节点N-1的处理与节点2类似。
假设节点1在预定时间内接收到节点2至节点N-1的数据确认，但是没有接收到节点N的数据确认，向客户端发送在预定时间内没有完全接收到其他节点数据确认的通知，客户端通知节点1至节点N继续切换到第二共识模式的操作。
再例如，节点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继续切换到第二共识模式的操作。
继续对分布式系统的节点切换到第二共识模式，并从第二共识模式切换的回第一共识模式的方式进行说明，对于从第二共识模式切换回第一共识模式，存在这样的几种方式：
方式1)主节点统计到形成共识的次数超出主节点共识次数阈值时，触发从节点切换回第一共识模式，主节点和从节点在切换到第一共识模式中时继承在第二共识模式中的节点状态(即节点作为主节点或从节点的状态保持不变)。
分布式系统处于第二共识模式中时，对于分布式系统中主节点(可以理解地，这里的主节点是针对一个共识周期而言)来说，如果主节点在第二共识模式中统计到与从节点针对所接收的消息达成共识的次数超过主节点共识次数阈值(如M次，M为根据对分布式系统中节点的共识的精度设定，一般地，精度要求越高，则预定次数越大，二者具有正相关的关系)，说明主节点与从节点针对连续来自客户端的消息已经达成较好的共识，为了进一步提升分布式系统的节点达成共识的效率，可以向从节点发送切换到第一共识模式的通知。
对于分布式系统中的从节点，在接收到主节点发送的切换到第一共识模式的通知后，即向主节点发送切换确认(承认主节点在切换到第一共识模式中时可以继续保持主节点的状态)，主节点与从节为保持当前节点的状态切换到第一共识模式，这样在第一共识模式中可以避免恶意节点成为主节点的情况，确保共识的效率。
可以理解，上述的共识节点数量阈值可以为分布式系统中的全部从节点的数量，或者，为分布式系统中在第一共识模式中要求达成共识的从节点的数量的最小值(即第一共识模式的容错性能所要求的共识节点数量的 最小值，低于该最小值后第一共识模式中达成的共识的可靠性无法得到保证)。
同理，上述的共识节点比例阈值可以对应分布式系统中的全部从节点的数量即100％，或者，为分布式系统中在第一共识模式中要求达成共识的从节点的数量的最小值如51％(即第一共识模式的容错性能所要求的共识节点数量的最小值，低于该最小值后第一共识模式中达成的共识的可靠性无法得到保证)。
例如，分布式系统在第二共识机制中，假设节点1为主节点，节点2至节点N为从节点，各节点就来自客户端的消息达成的共识进行计数，对于节点1来说，如果节点1与节点2至节点N就最近来自客户端的M个(主节点共识次数阈值)消息均达成共识，说明各节点之间已经达成较好的共识，节点1会向节点2至节点N广播切换到第一共识模式的通知，节点2至节点N向节点1发送切换确认，承认节点1在第一共识模式中仍然为主节点，节点2至节点2N继续作为从节点，即使节点2至节点N中出现恶意节点，也无法伪造来自客户端的消息，确保节点达成共识的效率。
方式2)主节点统计到形成共识的次数超出主节点共识次数阈值，主节点触发从节点切换回第一共识模式，当从节点统计到形成共识次数阈值超出从节点共识次数阈值时，从节点确认切换回第一共识模式，主节点和从节点在切换到第一共识模式中时继承在第二共识模式中的节点状态(即节点作为主节点或从节点的状态保持不变)。
分布式系统处于第二共识模式中时，主节点统计在第二共识模式中与其他节点(包括主节点和其他从节点)针对来自客户端的消息形成共识的次数，如果形成共识的次数超过从节点共识次数阈值(可以小于或等于主节点共识次数阈值，例如，可以为M/2)，则向主节点发送同意主节点在第一共识模式中继续作为主节点的通知，第二共识模式中的从节点在切换到 第一共识模式中时继续作为从节点，从而完成了切换到第一共识模式的选举操作，并继续在第一共识模式中针对来自客户端的消息达成共识。这样在第一共识模式中可以避免恶意节点成为主节点的情况，确保共识的效率。
在分布式系统的节点切换到第一共识模式之后，如果在第一共识模式中没有检测到异常节点，则继续保持在第一共识模式，如果在返回第一共识模式后仍然无法取得较好的共识(例如，仍然检测到恶意节点、异常节点或出错节点)，则重新切换到第二共识模式。
这里的预定数量/比例可以根据前述说明而理解，不再重复说明。
例如，分布式系统的主节点可以基于计数器在切换到第二共识模式后同步开始计时，在计时时间达到计时时间阈值(如10分钟)后，会触发分布式系统的从节点同步切换回第一共识模式，在第一共识模式中执行选举操作确定新的主节点和从节点；如果在切换到第一共识模式后仍然检测到异常节点，则再次切换回第二共识模式(切换到第一共识模式的方式可以根据前述说明而理解)，从而，在利用第二共识模式进行共识以保证分布式系统的容错性能的前提下，最大程度提升分布式系统达成共识的效率。
这里的预定数量/比例可以根据前述说明而理解，不再重复说明。
例如，分布式系统在第二共识机制中，假设节点1为主节点，节点2至节点N为从节点，各节点就来自客户端的消息达成的共识进行计数，对于节点1来说，如果节点1与节点2至节点N就最近来自客户端的M个(主节点共识次数阈值)消息均达成共识，说明各节点之间已经达成较好的共识，节点1会向节点2至节点N广播切换到第一共识模式的通知，对于节点2至节点N来说，以节点2为例，节点2统计在第二共识模式中形成共识的次数，如果超出M/2，则向节点1发送切换确认(确认节点1在切换到第一共识模式中时仍然作为主节点，节点2作为从节点)；节点3至节点N的处理与节点2类似，不再重复说明。
当节点1接收到节点2至节点N中每个节点发送的切换确认时，切换到第一共识模式并在第一共识模式中，节点1作为主节点、节点2至节点N作为从节点；如果节点1未接收到节点2至节点N每个节点发送的切换确认，则继续停留在第二共识模式，每间隔M/2次共识节点1继续向节点2至节点N发送且切换到第一共识模式的通知，直至接收到节点2至节点N全部节点的切换确认。
下面，以区块链系统(如维护对单独的个人或实体开放的联盟链系统)在第一共识模式中采用改进的RAFT(T-RAFT)算法，在第二共识模式中采用PBFT算法进行共识为例，可以理解，第一共识模式中还可以使用Paxos算法，第二共识模式中还可以采用BFT算法、BFT-RAFT等；第一共识模式可以采用任意共识效率高并且能检测到节点故障或者拜占庭节点的算法如T-RAFT算法，第二共识模式可以采用任意可以实现拜占庭容错的算法。
相关技术提供的RAFT算法只解决了多个节点数据一致性的问题，并不解决拜占庭容错，但是RAFT算法效率比较高。PBFT算法可以解决拜占庭容错，但是由于在PBFT算法中需要在节点中进行消息广播，实现的效率比较低。
在分布式网络应用到联盟链(对单独的个人或实体开放的区块链)的使用场景中，一般来说，区块链系统在绝大部分时间里是没有节点故障、也没有拜占庭节点问题，采用RAFT的算法可以高效达成节点之间的共识。
由于相关技术提供的RAFT解决了多个节点一致性的问题，效率比较高，但是没有解决节点间拜占庭容错的问题，而PBFT算法可以保证多个节点的一致性并且解决了各个节点间拜占庭容错，因此，本发明实施例中，只要在有节点出错或者有拜占庭问题的时候，能够自动采用要求PBFT算法实现各节点的共识，当所有节点都完全达成共识即没有拜占庭节点的时候，再自动切换到共识效率较高的RAFT算法实现各节点间的共识。
参见图8，图8是发明实施例提供的区块链系统采用RAFT算法达成共识的一个可选的流程示意图，客户端发送的消息主节点(leader节点)之后，主节点对接收的消息进行排序，按照排序分发给从节点(follower节点)，其他follower按照leader节点组织好的顺序存储消息到日志中，并向leader节点返回RPC结果(result)，然后leader节点将日志中消息存储在本地磁盘后，再向各从节点发一次提交(Commit)，则各从节点将消息中的日志存储在从节点的本地磁盘中，就完成了消息的一致性同步，具有较高的效率，但是不能解决拜占庭节点的问题。
参见图9，图9是发明实施例提供的区块链系统采用PBFT算法达成共识的一个可选的流程示意图，一个消息需要两次广播之后才能真正确认，由于依赖于广播，在达成共识的过程发送的消息数是节点数的平方级别，因此实现共识的效率比较低，但是能解决节点间拜占庭容错的问题。
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算法的一个可选的流程示意图，在图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算法共识的一个可选的流程示意图，这个消息流程示意图中，假设节点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算法的共识模式，各节点的连续共识次数将清零。只要有一个从节点不同意竞争节点转换为主节点，竞争节点马上恢复到原有状态即转换为PBFT算法的主节点，继续执行PBFT算法，各节点的共识统计次数继续累加，直到M+T的时候再次触发一次T-RAFT选举，如果不成功，下一次等到M+2T时刻触发，如此往复，M+x*T时刻触发，x是次数，直到主节点选举成功为止。
参见图14，图14是本发明实施例提供的区块链系统PBFT算法共识模式切换到T-RAFT算法共识模式的一个可选的流程示意图，PBFT算法的过程中，主节点即节点1统计到数据连续一致(共识)超过M次的时候，转变为T-RAFT的竞争节点状态，然后发起T-RAFT算法的选举，节点2、3和4收到选举请求(request vote)消息之后，判断是否也统计到连续数据一致的数量大于M/2(或者一个固定的值T)，如果是，则返回同意竞争节点转换为主节点的切换确认。
竞争节点收到2，3，4节点的切换确认，转换成主节点开始T-RAFT算法共识阶段。在T-RAFT选举的过程中，原来PBFT共识模式中的主节点(节点1)收到客户端的消息之后，不再发送定序消息，例如PBFT算法中的预备(PRE-PREPARE)消息，等到选举完成，在T-RAFT中将消息附在AppendEntries RPC中发送给从节点。
再结合实际应用中一个使用场景进行说明，参见图15，图15是本发明实施例提供的分布式系统应用于联盟链系统的一个可选的场景示意图，联盟链系统是对单独的个人或实体开放的，包括多个节点，每个节点向第三方支付机构、以及银行业务系统(作为客户端)提供接入，接收第三方支付机构、以及银行业务系统提交的交易记录，节点对提交的一个交易记录 形成共识后，才会将该交易记录存储在区块链的最新区块中存储，供第三方支付机构和签约银行根据各自的业务流水进行对账。
节点默认使用T-RAFT共识模式取得针对交易记录的共识，在出现异常节点时切换到PBFT共识模式对交易记录取得共识。
用户的第三方支付终端中绑定了用户在在银行的信用卡账户，用户与商家在线下或线上进行交易时，第三方支付终端可以通过预先获得的信用卡账号的预授权，从用户的信用卡账户中划款到商家的账户，形成一个交易记录。
对于这笔交易来说，第三方支付机构的业务系统会在分布式系统中所接入的主节点提交一个交易记录(例如，包括收款方、付款方和支付金额，携带第三方支付客户端的数字签名)；主节点对接收到交易记录验证数字签名成功后，将交易记录同步给其他的从节点(携带主节点的数字签名)，从节点验证交易记录的数字签名成功后，一方面向第三方支付机构业务系统返回结果(携带从节点数字签名、唯一性字段，在主节点为新选举出的主节点时，还携带交易记录的序列号)；另一方面，通知主节点同步完毕；主节点在确认各从节点同步完成后将交易记录存储在区块链的最新区块中并通知各从节点，从节点执行相同操作，完成交易记录的持久化存储。
对于上述针对交易记录的共识过程，如果客户端根据从节点返回的结果确定主节点为恶意节点，或从节点出现故障，则会触发联盟链系统切换到PBFT共识模式取得针对交易记录的共识，确保交易记录能够在各节点的区块链中顺利存储；根据联盟链系统对第三方支付结构业务系统后续提交的交易记录的共识情况，如取得较好的公式(主节点与其他节点连续M次共识)，可以切换回T-RAFT共识模式以提升共识的效率。
综上，本发明实施例具有以下有益效果：
1)客户端与节点之间、节点之间采用数字签名的方式保证通信的可靠 性，避免消息伪装的情况，保证分布式系统内部通信的可靠性。
2)从节点在接收主节点发送的消息时，会直接向客户端返回结果，在结果中携带必要的信息如唯一性字段、消息序列号和数字签名等，这样，客户端可以直接根据从节点返回的结果来判定从节点达成共识的情况，能够容易地检测出异常节点。
3)在检测到异常节点时，能够从默认的共识效率高的第一共识模式切换到容错性能更优的第二共识模式，确保分布式系统的共识在出现异常时也能够顺利达成。
4)在第二共识模式中一旦达成较好的共识(例如，根据共识次数判断)，则再次切换到第一共识模式，这种自适应的共识模式切换实现了共识效率和容错性能的最佳融合。在分布式系统的运行的网络状态良好的多数时间内、实现了共识效率高的技术效果，节点故障或者有拜占庭容错节点时保真分布式系统的业务功能正常处理。
本领域的技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储通信状态处理装置、随机存取存储器(RAM，Random Access Memory)、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机通信状态处理装置(可以是个人计算机、服务器、或者网络通信状态处理装置等)执行本发明各 个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储通信状态处理装置、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (35)

  1. 一种分布式系统，包括：
    客户端和多个节点；
    所述节点，配置为当第一共识模式中新的共识周期到达时，通过执行选举操作确定处于主节点的状态或处于从节点的状态；
    所述节点，配置为当处于主节点的状态时，验证所述客户端发送的消息的数字签名，将所述消息发送到所述从节点；
    所述节点，配置为当处于主节点的状态时，接收到超出预定数量的所述从节点的确认接收通知，验证所述确认接收通知的数字签名后持久化存储所述消息，向所述从节点发送存储消息通知；
    所述节点，还配置为当处于从节点的状态时，接收到所述主节点发送的所述消息时向所述客户端返回结果，验证从所述主节点所接收的消息的数字签名，向所述主节点发送确认接收通知；
    所述节点，配置为当处于从节点的状态时，验证从所述主节点所接收的存储消息通知的数字签名，持久化存储从所述主节点所接收的消息；
    所述客户端，配置为根据所述从节点接收到所述消息时返回的结果，确定所述分布式系统中的异常节点。
  2. 如权利要求1所述的分布式系统，其中，
    所述客户端，还配置为验证所接收结果的数字签名后，将所接收结果包括的唯一性字段与所发送消息的唯一性字段比较，确定不一致的唯一性字段对应的从节点为出错节点，确定未返回结果的从节点为故障节点。
  3. 如权利要求1所述的分布式系统，其中，
    所述客户端，还配置为根据所接收结果携带的序列号与所发送消息的序列号比较，当发送不一致序列号的从节点的数量超出不一致数量阈值时，判定所述主节点为恶意节点。
  4. 如权利要求1所述的分布式系统，其中，
    所述客户端，还配置为确定所述主节点为恶意节点，或者，确定所述从节点中存在故障节点时，触发所述分布式系统中节点切换到第二共识模式。
  5. 如权利要求4所述的分布式系统，其中，
    所述节点，还配置为当处于切换到所述第二共识模式的准备阶段时，将所述节点持久化存储的消息的哈希值，与所述分布式系统中节点持久化存储的消息的哈希值比较，确认一致时向所述客户端发送一致性确认，所述一致性确认携带相应节点的数字签名；
    所述客户端，还配置为在预定时间内接收到全部所述节点的一致性确认时，通知所述分布式系统中节点返回所述第一共识模式，未在所述预定时间内接收到全部所述节点的一致性确认时，通知所述分布式系统中节点继续切换到所述第二共识模式。
  6. 如权利要求4所述的分布式系统，其中，
    所述节点，还配置为当处于切换到所述第二共识模式的准备阶段时，将所述节点持久化存储的消息的哈希值，与所述分布式系统中节点持久化存储的消息的哈希值比较，确认一致时向消息的发送节点发送数据确认，所述数据确认携带相应节点的数字签名；
    所述客户端，还配置为在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时，或在预定时间内分布式系统中节点未接收到数据确认时，触发所述分布式系统中节点继续切换到所述第二共识模式。
  7. 如权利要求4所述的分布式系统，其中，
    所述节点，还配置为当处于主节点的状态，并在所述第二共识模式中统计到的的次数超过主节点共识次数阈值时，与所述从节点切换到所述第一共识模式，其中，所统计到的次数为与所述从节点针对所接收的消息形 成共识的计数。
  8. 如权利要求7所述的分布式系统，其中，
    所述节点，还配置为当处于主节点的状态时，并在所统计到的次数超过主节点共识次数阈值时，向所述从节点发送切换到所述第一共识模式的通知，并在接收到全部所述从节点发送的切换确认时，与所述从节点开始同步切换到所述第一共识模式。
  9. 如权利要求8所述的分布式系统，其中，
    所述节点，还配置为当处于从节点的状态，接收到切换到所述第一共识模式的通知，且统计到针对所接收的消息形成共识的次数超过从节点共识次数阈值时，向所述主节点发送切换确认。
  10. 如权利要求1所述的分布式系统，其中，
    所述节点，还配置为未接收到所述主节点的心跳信息时，或者，所述主节点为恶意节点时，通过重新执行选举操作确定处于主节点的状态或处于从节点的状态。
  11. 如权利要求1所述的分布式系统，其中，
    所述节点，还配置为在新的共识周期到达、且未接收到任意节点发送的心跳信息时，向所述分布式系统中节点发送选举请求，当接收预定数量的节点返回的选举确认时，转换为主节点的状态并定期向所述分布式系统中节点发送心跳信息；
    其中，所述选举确认为所述分布式系统中节点发送，且在发送之前验证所述选取请求携带的数字签名；
    所述节点，还配置为在新的共识周期到达、且接收到所述分布式系统中节点发送的心跳信息时，转换为从节点的状态。
  12. 一种消息处理方法，包括：
    当第一共识模式中新的共识周期到达时，分布式系统中的节点执行选 举操作，通过选举操作确定处于主节点的状态或处于从节点的状态；
    当所述节点处于主节点的状态时，所述节点执行以下操作：
    接收所述客户端的消息，验证所述消息的数字签名，将所述消息发送到所述从节点，以及，
    接收到超出预定数量的所述从节点的确认接收通知，验证所述确认接收消息的数字签名后持久化存储所述消息，向所述从节点发送存储消息通知；
    其中，所述从节点接收到所述消息时返回的结果，用于供所述客户端确定所述分布式系统中的异常节点。
  13. 如权利要求12所述的消息处理方法，其中，还包括：
    当所述节点处于从节点的状态时，所述节点执行以下操作：
    接收到所述主节点发送的消息并向所述客户端返回结果，验证所接收的消息的数字签名后向所述主节点发送确认接收通知，以及，
    验证所接收的存储消息通知的数字签名后持久化存储所接收的消息。
  14. 如权利要求12所述的消息处理方法，其中，
    当所述节点处于从节点的状态时，所述从节点向所述客户端返回结果携带以下信息：所述消息的唯一性字段，所述从节点的数字签名；
    所述结果用于供所述客户端验证携带的数字签名，将所述结果包括的唯一性字段与所发送消息的唯一性字段比较，确定不一致的唯一性字段对应的从节点为出错节点，以及确定未返回相应结果的从节点为故障节点。
  15. 如权利要求12所述的消息处理方法，其中，
    当所述节点处于从节点的状态时，所述从节点所返回的结果携带所述从节点所接收消息的序列号；
    所述结果用于供所述客户端将携带的序列号与所发送消息的序列号比较，当发送不一致序列号的从节点的数量超出不一致数量阈值时，确定所 述主节点为恶意节点。
  16. 如权利要求12所述的消息处理方法，其中，还包括：
    当所述客户端确定所述主节点为恶意节点，或者，确定所述从节点中存在故障节点时，所述节点响应于所述客户端的触发而切换到第二共识模式。
  17. 如权利要求16所述的消息处理方法，其中，还包括：
    当所述节点处于切换到所述第二共识模式的准备阶段时，所述节点执行以下操作：
    将所述节点持久化存储的消息的哈希值，与所述分布式系统中节点持久化存储的消息的哈希值比较，确认一致时向所述客户端发送一致性确认，所述一致性确认携带相应节点的数字签名；
    当所述客户端在预定时间内接收到全部所述节点的一致性确认时，所述节点响应于所述客户端的通知，继续切换到所述第一共识模式；
    当所述客户端未在预定时间内接收到全部所述节点的一致性确认时，所述节点响应于所述客户端的针对通知，继续切换到所述第二共识模式。
  18. 如权利要求16所述的消息处理方法，其中，还包括：
    当所述节点处于切换到所述第二共识模式的准备阶段时，所述节点执行以下操作：
    将所述节点持久化存储的消息的哈希值，与所述分布式系统中节点持久化存储的消息的哈希值比较，确认一致时向消息的发送节点发送数据确认，所述数据确认携带相应节点的数字签名；
    当在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时，或在所述预定时间内分布式系统中节点未接收到数据确认时，所述节点响应于所述客户端的触发，继续切换到所述第二共识模式。
  19. 如权利要求16所述的消息处理方法，其中，还包括：
    当所述节点处于主节点的状态，且在所述第二共识模式中统计到的次数超过主节点共识次数阈值时，与所述从节点切换到所述第一共识模式；
    其中，所统计到的次数为与所述从节点针对所接收的消息形成共识的计数。
  20. 如权利要求19所述的消息处理方法，其中，所述与所述从节点切换到所述第一共识模式，包括：
    当所述主节点向所述从节点发送切换到所述第一共识模式的通知，并接收到全部所述从节点发送的切换确认时，与所述从节点开始同步切换到所述第一共识模式。
  21. 如权利要求20所述的消息处理方法，其中，还包括：
    当所述节点处于从节点的状态时执行以下操作：
    当接收到切换到所述第一共识模式的通知时，统计针对所接收的消息形成共识的次数，当所统计到的次数超过从节点共识次数阈值时，向所述主节点发送切换确认。
  22. 如权利要求12所述的消息处理方法，其中，还包括：
    当所述从节点未接收到所述主节点的心跳信息时，或者，所述主节点为恶意节点时，所述分布式系统中的节点通过重新执行选举操作确定处于主节点的状态或处于从节点的状态。
  23. 如权利要求12所述的消息处理方法，其中，
    当新的共识周期到达、且未接收到心跳信息时，所述节点向所述分布式系统中节点发送选举请求，所述选举请求携带所述节点的数字签名；
    当接收预定数量的节点返回的选举确认时，转换为主节点的状态，所述节点定期向所述分布式系统中节点发送心跳信息；
    其中，所述选举确认为所述分布式系统中节点验证所述选取请求携带的数字签名后发送；
    当新的共识周期到达、且接收到所述分布式系统中节点发送的心跳信息时转换为从节点的状态。
  24. 一种消息处理方法，包括：
    客户端向分布式系统的节点中的主节点发送消息，所述消息携带所述客户端的数字签名；
    其中，所述数字签名用于供所述主节点进行验证，并将所接收的消息携带所述主节点的数字签名，发送给所述分布式系统中的从节点；
    所述客户端接收所述从节点在接收到所述消息时返回的结果；
    所述客户端根据所述从节点接收到所述消息时返回的结果，确定所述分布式系统中的异常节点。
  25. 如权利要求24所述的消息处理方法，其中，所述客户端根据所述从节点接收到所述消息时返回的结果，确定所述分布式系统中的异常节点，包括：
    所述客户端验证所接收结果的数字签名后，将所接收结果包括唯一性字段与所发送消息的唯一性字段比较，确定不一致的唯一性字段对应的从节点为出错节点，以及确定未返回相应结果的从节点为故障节点。
  26. 如权利要求24所述的消息处理方法，其中，所述客户端根据所述从节点接收到所述消息时返回的结果，确定所述分布式系统中的异常节点，包括：
    所述客户端根据所接收结果携带的序列号与所发送消息的序列号比较，当发送不一致序列号的从节点的数量超出不一致数量阈值时，判定所述主节点为恶意节点。
  27. 如权利要求24所述的消息处理方法，其中，还包括：
    当所述客户端确定所述主节点为恶意节点时，或者，当所述客户端确定所述从节点中存在故障节点时，触发所述分布式系统的节点切换到第二 共识模式。
  28. 如权利要求27所述的消息处理方法，其中，还包括：
    在所述客户端在预定时间内接收到全部所述节点的一致性确认时，通知全部所述节点返回所述第一共识模式；
    当所述客户端未在预定时间内接收到全部所述节点的一致性确认时，通知全部所述节点继续切换到所述第二共识模式；
    其中，所述一致性确认携带所述节点的数字签名，由所述节点处于切换到所述第二共识模式的准备阶段时发送，且在发送前确定所述节点持久化存储的消息的哈希值、与所述分布式系统中节点持久化存储的消息的哈希值一致。
  29. 如权利要求27所述的消息处理方法，其中，还包括：
    当在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时，或在预定时间内分布式系统中节点未接收到数据确认时，所述客户端触发所述分布式系统中节点继续切换到所述第二共识模式；
    其中，所述数据确认携带相应节点的数字签名，由所述节点在处于切换到所述第二共识模式的准备阶段时发送，且在发送前确定所述节点持久化存储的消息的哈希值、与所述分布式系统中持久化存储的消息的哈希值一致。
  30. 一种分布式系统中的节点，包括：
    选举单元，配置为当第一共识模式中新的共识周期到达时通过执行选举操作，通过选举操作确定处于主节点的状态或处于从节点的状态；
    主节点单元，配置为当所述节点处于主节点的状态时，接收所述客户端的消息，验证所述消息的数字签名，将所述消息发送到所述从节点，以及，
    接收到超出预定数量的所述从节点的确认接收通知，验证所述确认接 收消息的数字签名后持久化存储所述消息，向所述从节点发送存储消息通知；
    其中，所述从节点接收到所述消息时返回的结果，用于供所述客户端确定所述分布式系统中的异常节点。
  31. 一种分布式系统中的节点，包括有一个或多个处理器以及存储器，以及一个或一个以上的程序，其中，所述一个或一个以上的程序存储于存储器中，所述程序可以包括一个或一个以上的每一个对应于一组指令的单元，所述一个或多个处理器被配置为执行指令时实现消息处理方法，所述消息处理方法包括：
    当第一共识模式中新的共识周期到达时，分布式系统中的节点执行选举操作，通过选举操作确定处于主节点的状态或处于从节点的状态；
    当所述节点处于主节点的状态时，所述节点执行以下操作：
    接收所述客户端的消息，验证所述消息的数字签名，将所述消息发送到所述从节点，以及，
    接收到超出预定数量的所述从节点的确认接收通知，验证所述确认接收消息的数字签名后持久化存储所述消息，向所述从节点发送存储消息通知；
    其中，所述从节点接收到所述消息时返回的结果，用于供所述客户端确定所述分布式系统中的异常节点。
  32. 一种分布式系统中的客户端，包括：
    通信单元，配置为向分布式系统的节点中的主节点发送消息，所述消息携带所述客户端的数字签名；
    其中，所述数字签名用于供所述主节点进行验证，并将所接收的消息携带所述主节点的数字签名，发送给所述分布式系统中的从节点；
    所述通信单元，配置为接收所述从节点在接收到所述消息时返回的结 果；
    检测单元，配置为根据所述从节点接收到所述消息时返回的结果，确定所述分布式系统中的异常节点。
  33. 一种分布式系统中的客户端，包括：包括有一个或多个处理器以及存储器，以及一个或一个以上的程序，其中，所述一个或一个以上的程序存储于存储器中，所述程序可以包括一个或一个以上的每一个对应于一组指令的单元，所述一个或多个处理器被配置为执行指令时实现消息处理方法，所述消息处理方法包括：
    客户端向分布式系统的节点中的主节点发送消息，所述消息携带所述客户端的数字签名；
    其中，所述数字签名用于供所述主节点进行验证，并将所接收的消息携带所述主节点的数字签名，发送给所述分布式系统中的从节点；
    所述客户端接收所述从节点在接收到所述消息时返回的结果；
    所述客户端根据所述从节点接收到所述消息时返回的结果，确定所述分布式系统中的异常节点。
  34. 一种存储介质，存储有可执行程序，用于引起处理器执行所述可执行程序时，实现如权利要求12至23任一项所述的消息处理方法。
  35. 一种存储介质，存储有可执行程序，用于引起处理器执行所述可执行程序时，实现如权利要求24至29任一项所述的消息处理方法。
PCT/CN2018/080574 2017-03-30 2018-03-26 分布式系统、消息处理方法、节点、客户端及存储介质 WO2018177264A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2019531777A JP6883106B2 (ja) 2017-03-30 2018-03-26 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体
EP18777404.7A EP3605947B1 (en) 2017-03-30 2018-03-26 Distributed system, message processing method, node, client, and storage medium
KR1020197027223A KR102248454B1 (ko) 2017-03-30 2018-03-26 분산 시스템, 메시지 처리 방법, 노드, 클라이언트 및 기록매체
US16/383,162 US11237896B2 (en) 2017-03-30 2019-04-12 Distributed system, message processing method, nodes, client, and storage medium
US17/542,971 US11775377B2 (en) 2017-03-30 2021-12-06 Distributed system, message processing method, nodes, client, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710203499.XA CN106789095B (zh) 2017-03-30 2017-03-30 分布式系统及消息处理方法
CN201710203499.X 2017-03-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/383,162 Continuation US11237896B2 (en) 2017-03-30 2019-04-12 Distributed system, message processing method, nodes, client, and storage medium

Publications (1)

Publication Number Publication Date
WO2018177264A1 true WO2018177264A1 (zh) 2018-10-04

Family

ID=58965529

Family Applications (1)

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

Country Status (7)

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

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109816021A (zh) * 2019-01-28 2019-05-28 网易（杭州）网络有限公司 智能合约处理方法及装置、系统、存储介质和电子设备
CN110061856A (zh) * 2019-03-07 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的通信方法、装置及电子设备
WO2020135435A1 (zh) * 2018-12-29 2020-07-02 杭州复杂美科技有限公司 主链平行链架构系统及区块同步方法、设备和存储介质
JP2020519959A (ja) * 2019-03-18 2020-07-02 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ビュー変更プロトコルを終了するためのシステムおよび方法
WO2020218478A1 (ja) * 2019-04-26 2020-10-29 株式会社シーズ 電子機器、情報処理システム
JP2020184291A (ja) * 2019-04-26 2020-11-12 株式会社シーズ 電子機器、情報処理システム
US10922195B2 (en) 2019-03-18 2021-02-16 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
US10977135B2 (en) 2019-03-18 2021-04-13 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US11057504B2 (en) 2019-03-18 2021-07-06 Advanced New Technologies Co., Ltd. System and method for ending view change protocol
JP2022533396A (ja) * 2019-06-26 2022-07-22 ジンドン テクノロジー ホールディング カンパニー リミテッド ブロックチェーンコンセンサス方法、装置及びシステム
CN116192692A (zh) * 2022-12-30 2023-05-30 蚂蚁区块链科技(上海)有限公司 一种区块链网络中的共识数据分发方法和区块链网络

Families Citing this family (135)

* 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
US10747753B2 (en) 2015-08-28 2020-08-18 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
LT3539026T (lt) 2016-11-10 2022-03-25 Swirlds, Inc. Būdai ir aparatas paskirstytajai duomenų bazei, apimančiai anonimines įvestis
WO2018118930A1 (en) 2016-12-19 2018-06-28 Swirlds, Inc. Methods and apparatus for a distributed database that enables deletion of events
CN110445619B (zh) 2017-03-30 2020-10-16 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
CN108063787A (zh) * 2017-06-26 2018-05-22 杭州沃趣科技股份有限公司 基于分布式一致性状态机实现双活架构的方法
KR102415097B1 (ko) 2017-07-11 2022-06-29 스월즈, 인크. 네트워크 내의 분산 데이터베이스를 효율적으로 구현하기 위한 방법들 및 장치
CN109426567B (zh) * 2017-08-22 2021-05-04 汇链丰(北京)科技有限公司 一种区块链的节点部署和选举方法
US10943680B1 (en) * 2017-09-07 2021-03-09 Massachusetts Mutual Life Insurance Company Intelligent health-based blockchain
CN108023729B (zh) * 2017-10-13 2020-06-23 中国银联股份有限公司 区块链网络及其交易方法
CN107819749A (zh) 2017-10-26 2018-03-20 平安科技（深圳）有限公司 基于以太坊的区块链系统和交易数据处理方法
RU2740865C1 (ru) 2017-11-01 2021-01-21 Свирлдз, Инк. Способы и устройство для эффективной реализации базы данных, поддерживающей быстрое копирование
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 上海指旺信息科技有限公司 基于区块链的电子钱包平台
EP3741081B1 (en) * 2018-01-16 2021-10-13 Nchain Holdings Limited 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 中国科学院计算技术研究所 基于一致性哈希算法的区块链共识算法和系统
CN108846010B (zh) * 2018-04-28 2021-12-14 腾讯科技（深圳）有限公司 网络中产品溯源的方法、系统、计算机系统和存储介质
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 广州杰赛科技股份有限公司 一种基于区块链的数据上链系统、方法及存储介质
CN109194646B (zh) * 2018-08-30 2021-05-25 东北大学 一种基于区块链的安全认证数据存取方法
CN109347906B (zh) * 2018-08-30 2021-04-20 腾讯科技（深圳）有限公司 一种数据传输方法、装置、与服务器
CN108989465B (zh) * 2018-08-30 2021-03-12 交叉信息核心技术研究院(西安)有限公司 共识方法、服务器、存储介质及分布式系统
CN109213828B (zh) * 2018-09-18 2021-08-20 百度在线网络技术（北京）有限公司 区块生成方法、装置、设备及存储介质
CN109344630B (zh) * 2018-09-18 2021-07-02 百度在线网络技术（北京）有限公司 区块生成方法、装置、设备和存储介质
CN109241362B (zh) * 2018-09-18 2020-12-01 百度在线网络技术（北京）有限公司 区块生成方法、装置、设备及存储介质
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 阿里巴巴集团控股有限公司 联盟链中的请求处理方法、系统、装置及设备
CN109495516A (zh) * 2019-01-07 2019-03-19 国网江苏省电力有限公司无锡供电分公司 基于区块链的电力物联网终端接入方法
CN109857751A (zh) * 2019-01-23 2019-06-07 平安科技（深圳）有限公司 基于区块链的跨平台数据更新方法、装置和计算机设备
CN109831425B (zh) * 2019-01-25 2022-02-15 中国联合网络通信集团有限公司 区块链共识方法、装置、设备及计算机可读存储介质
CN109828979A (zh) * 2019-01-31 2019-05-31 浙江小泰科技有限公司 一种数据一致性检测方法及系统
US11226910B2 (en) * 2019-03-04 2022-01-18 Qualcomm Incorporated Ticket based request flow control
CN109902074B (zh) * 2019-04-17 2021-02-09 江苏全链通信息科技有限公司 基于数据中心的日志存储方法和系统
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 阿里巴巴集团控股有限公司 一种基于联盟链的对账方法、装置及电子设备
CN110096381B (zh) * 2019-05-10 2021-05-07 百度在线网络技术（北京）有限公司 远程过程调用的实现方法、装置、设备和介质
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
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 支付宝(杭州)信息技术有限公司 一种区块链的签名方法和系统
CA3098932C (en) * 2019-11-06 2021-09-28 Alipay (Hangzhou) Information Technology Co., Ltd. Data security of shared blockchain data storage based on error correction code
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 杭州趣链科技有限公司 一种面向区块链轻节点的多中心接入的管理方法和装置
CN111107103B (zh) * 2019-12-31 2022-04-15 南京可信区块链与算法经济研究院有限公司 一种联盟链的性能维持方法、系统及存储介质
CN111179063B (zh) * 2019-12-31 2023-06-23 中国银行股份有限公司 基于区块链的信用卡业务数据处理方法、系统及相关节点
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 哈尔滨工业大学 一种应用于许可链的二元加权拜占庭容错共识方法
CN111343208B (zh) * 2020-05-21 2020-08-14 腾讯科技（深圳）有限公司 基于区块链的数据检测方法、装置及计算机可读存储介质
CN111654415B (zh) * 2020-05-28 2021-09-10 腾讯科技（深圳）有限公司 基于区块链的信息处理方法、装置、设备及可读存储介质
CN111756823A (zh) * 2020-06-12 2020-10-09 山西警察学院 基于简化拜占庭容错算法的应用于公安系统的开放许可链
CA3094539A1 (en) * 2020-07-23 2022-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
CN113779145B (zh) * 2021-08-27 2024-07-16 浙商银行股份有限公司 一种区块链吞吐量提升系统及方法
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 四川汉唐云分布式存储技术有限公司 一种基于消息分发确定时序的交易系统
CN116074328B (zh) * 2023-03-01 2023-06-27 中国信息通信研究院 区块链网络中的区块传输方法、装置、设备和介质
CN116488946B (zh) * 2023-06-21 2023-09-15 积至网络(北京)有限公司 基于持续多模表决的恶意节点检测方法
CN117220884A (zh) * 2023-09-05 2023-12-12 上海雷龙信息科技有限公司 一种数字签名交互验证方法、系统、设备和介质
CN117811746A (zh) * 2023-12-27 2024-04-02 国网安徽省电力有限公司营销服务中心 一种基于量子拜占庭共识的电力数据传输方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106060036A (zh) * 2016-05-26 2016-10-26 布比（北京）网络技术有限公司 去中心化共识方法及装置
CN106503589A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 区块链交易信息正确性的校验方法、装置及系统
CN106534273A (zh) * 2016-10-31 2017-03-22 中金云金融（北京）大数据科技股份有限公司 区块链元数据存储系统及其存储方法与检索方法
CN106789095A (zh) * 2017-03-30 2017-05-31 腾讯科技（深圳）有限公司 分布式系统及消息处理方法

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002512736A (ja) * 1997-03-18 2002-04-23 テレフオンアクチーボラゲツト エル エム エリクソン（パブル） トレンチで分離されたバイポーラデバイス
ATE524914T1 (de) * 2002-03-27 2011-09-15 Ibm Dynamische adressierung in transienten netzwerken
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 杭州云象网络技术有限公司 一种基于区块链的证据保全方法及装置
CN106445711B (zh) 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法
CN106487801B (zh) * 2016-11-03 2019-10-11 江苏通付盾科技有限公司 基于区块链的信息验证方法及装置
CN107391320B (zh) * 2017-03-10 2020-07-10 创新先进技术有限公司 一种共识方法及装置
CN107368507B (zh) * 2017-03-28 2020-03-27 创新先进技术有限公司 一种基于区块链的共识方法及装置
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
EP3836512B1 (en) * 2018-11-07 2022-07-13 Advanced New Technologies Co., Ltd. Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization
PL3580913T3 (pl) * 2019-03-18 2021-06-28 Advanced New Technologies Co., Ltd. Przywracanie systemu konsensusu po przestoju
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
US11411721B2 (en) * 2019-09-27 2022-08-09 Cypherium Blockchain Inc. Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106060036A (zh) * 2016-05-26 2016-10-26 布比（北京）网络技术有限公司 去中心化共识方法及装置
CN106503589A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 区块链交易信息正确性的校验方法、装置及系统
CN106534273A (zh) * 2016-10-31 2017-03-22 中金云金融（北京）大数据科技股份有限公司 区块链元数据存储系统及其存储方法与检索方法
CN106789095A (zh) * 2017-03-30 2017-05-31 腾讯科技（深圳）有限公司 分布式系统及消息处理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ONGARO, D. ET AL.: "In Search of an Understandable Consensus Algorithm", 2014 USENIX ANNUAL TECHNICAL CONFERENCE, 20 June 2014 (2014-06-20), XP055402740 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020135435A1 (zh) * 2018-12-29 2020-07-02 杭州复杂美科技有限公司 主链平行链架构系统及区块同步方法、设备和存储介质
CN109816021A (zh) * 2019-01-28 2019-05-28 网易（杭州）网络有限公司 智能合约处理方法及装置、系统、存储介质和电子设备
CN110061856A (zh) * 2019-03-07 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的通信方法、装置及电子设备
US11263067B2 (en) 2019-03-18 2022-03-01 Advanced New Technologies Co., Ltd. System and method for ending view change protocol
US11347598B2 (en) 2019-03-18 2022-05-31 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
JP2020519959A (ja) * 2019-03-18 2020-07-02 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ビュー変更プロトコルを終了するためのシステムおよび方法
US10922195B2 (en) 2019-03-18 2021-02-16 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
US10977135B2 (en) 2019-03-18 2021-04-13 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US11057504B2 (en) 2019-03-18 2021-07-06 Advanced New Technologies Co., Ltd. System and method for ending view change protocol
JP6991427B2 (ja) 2019-04-26 2022-01-12 株式会社シーズ 電子機器、情報処理システム
CN114073023A (zh) * 2019-04-26 2022-02-18 株式会社赛斯 电子设备和信息处理系统
JP2020184291A (ja) * 2019-04-26 2020-11-12 株式会社シーズ 電子機器、情報処理システム
WO2020218478A1 (ja) * 2019-04-26 2020-10-29 株式会社シーズ 電子機器、情報処理システム
CN114073023B (zh) * 2019-04-26 2024-05-31 株式会社赛斯 电子设备和信息处理系统
JP2022533396A (ja) * 2019-06-26 2022-07-22 ジンドン テクノロジー ホールディング カンパニー リミテッド ブロックチェーンコンセンサス方法、装置及びシステム
CN116192692A (zh) * 2022-12-30 2023-05-30 蚂蚁区块链科技(上海)有限公司 一种区块链网络中的共识数据分发方法和区块链网络

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2018177264A1 (zh) 分布式系统、消息处理方法、节点、客户端及存储介质
US11907174B2 (en) Systems and methods for managing data generation, storage, and verification in a distributed system having a committee of validator nodes
US20210295321A1 (en) Methods for decentralized digital asset transfer and smart contract state transition
US11128522B2 (en) Changing a master node in a blockchain system
EP3780553B1 (en) Blockchain-based transaction consensus processing method and apparatus, and electrical device
CN112035889B (zh) 计算外包的区块链隐私验证方法、装置及计算机设备
US11323475B2 (en) System and method for detecting replay attack
US10735464B2 (en) System and method for detecting replay attack
JP2020512708A5 (zh)
CN111475576B (zh) 基于区块链的分布式数据库存储方法及系统
CN112685796A (zh) 一种基于区块链的区块共识方法以及相关设备
WO2020087042A1 (en) Blockchain consensus systems and methods involving a time parameter
CN111212139A (zh) 对信任节点信息进行更新的方法及装置
CN113064764B (zh) 在区块链系统中执行区块的方法及装置
CN104092673A (zh) 一种实现网间单向数据安全传输的系统和方法
CN111064813B (zh) 在区块链共识处理时进行处理消息同步的方法及装置
Bazzi et al. Clairvoyant state machine replication
US20240073045A1 (en) Blockchain-based data processing method and apparatus, device, medium, and product
Jalalzai et al. The hermes BFT for blockchains
CN112994891B (zh) 一种基于门限签名的交易请求共识方法和系统
CN110555764A (zh) 一种去中心化环境下区块链达成一致性的方法及系统
Friedman et al. Hardening cassandra against byzantine failures
US20240223386A1 (en) Blockchain system with improved throughput by splitting blocks, and its computer program
Liu et al. Kronos: A Robust Sharding Blockchain Consensus with Optimal Communication Overhead
CN115796863A (zh) 区块链系统的共识方法及相关设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18777404

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019531777

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197027223

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018777404

Country of ref document: EP

Effective date: 20191030