WO2023179056A1 - 区块链网络的共识处理方法、装置、设备及存储介质、程序产品 - Google Patents

区块链网络的共识处理方法、装置、设备及存储介质、程序产品 Download PDF

Info

Publication number
WO2023179056A1
WO2023179056A1 PCT/CN2022/132238 CN2022132238W WO2023179056A1 WO 2023179056 A1 WO2023179056 A1 WO 2023179056A1 CN 2022132238 W CN2022132238 W CN 2022132238W WO 2023179056 A1 WO2023179056 A1 WO 2023179056A1
Authority
WO
WIPO (PCT)
Prior art keywords
consensus
blockchain network
nodes
speed
type
Prior art date
Application number
PCT/CN2022/132238
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 US18/239,843 priority Critical patent/US20230409450A1/en
Publication of WO2023179056A1 publication Critical patent/WO2023179056A1/zh

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/0793—Remedial or corrective actions
    • 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/2046—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 where the redundant components share persistent storage
    • 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
    • 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/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • 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/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • 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/50—Testing arrangements
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • 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
    • 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/40—Network security protocols
    • 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/88—Monitoring involving counting
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • This application relates to blockchain technology, and in particular to a consensus processing method, device, equipment, storage medium, and program product for a blockchain network.
  • the consensus algorithms currently used in blockchain networks tend to focus on the efficiency of reaching consensus, but have limited fault tolerance for node abnormalities, or only focus on fault tolerance in the process of reaching consensus.
  • Fault tolerance refers to the presence of faults.
  • the consensus algorithm switching flexibility in the blockchain network is not high, which affects the fault tolerance performance of the blockchain network.
  • Embodiments of the present application provide a consensus processing method, device, equipment, computer-readable storage medium, and computer program product for a blockchain network, which can improve the fault-tolerance performance of the blockchain network.
  • Embodiments of the present application provide a consensus processing method for a blockchain network, which is executed by an electronic device. Multiple nodes included in the blockchain network are run in the electronic device, and at least some of the nodes among the multiple nodes are configured to be based on consensus. The algorithm performs consensus processing on the messages sent by the client;
  • the methods include:
  • a consensus environment detection is performed on the blockchain network to obtain a detection result, wherein the detection result represents that at least some of the nodes have determined the consensus environment based on the consensus algorithm. Whether there was an error when the message was consensus;
  • the types of the consensus algorithm include a first type and a second type.
  • the consensus performance of the first type of consensus algorithm is higher than the consensus performance of the second type of consensus algorithm.
  • the consensus algorithm of the second type The fault tolerance performance is greater than the fault tolerance performance of the first type of consensus algorithm.
  • Embodiments of the present application provide a consensus processing device for a blockchain network.
  • the blockchain network includes multiple nodes, and at least some of the multiple nodes are configured to perform consensus processing on messages sent by the client based on a consensus algorithm.
  • the device includes:
  • a data collection blockchain module configured to obtain the type of the consensus algorithm currently running on the blockchain network
  • a consensus detection blockchain module configured to perform consensus environment detection on the blockchain network in response to the blockchain network meeting the consensus environment detection conditions to obtain a detection result, wherein the detection result represents at least part of the Whether the node made an error when consensus on the message based on the consensus algorithm;
  • a consensus switching blockchain module configured to switch the consensus algorithm currently running on the blockchain network to other types of consensus algorithms in response to the detection result satisfying the consensus algorithm switching condition corresponding to the type;
  • the types of the consensus algorithm include a first type and a second type.
  • the consensus performance of the first type of consensus algorithm is higher than the consensus performance of the second type of consensus algorithm.
  • the consensus algorithm of the second type The fault tolerance performance is greater than the fault tolerance performance of the first type of consensus algorithm.
  • An embodiment of the present application provides an electronic device, which includes:
  • Memory used to store executable instructions
  • the processor is configured to implement the consensus processing method of the blockchain network provided by the embodiment of the present application when executing the executable instructions stored in the memory.
  • Embodiments of the present application provide a computer-readable storage medium that stores executable instructions for causing the processor to implement the consensus processing method of the blockchain network provided by the embodiments of the present application.
  • An embodiment of the present application provides a computer program product, which includes a computer program or instructions.
  • the computer program or instructions are executed by a processor, the consensus method of the blockchain network provided by the embodiment of the present application is implemented.
  • the consensus algorithm is switched on the blockchain network based on the consensus detection results and the switching conditions corresponding to the consensus algorithm, making the consensus algorithm switching of the blockchain network more flexible and more in line with the fault tolerance requirements of the blockchain network. , improve the fault tolerance and operational stability of the blockchain network. Furthermore, the blockchain network can adaptively switch consensus algorithms according to changes in business scenarios to meet the needs of different application scenarios.
  • Figure 1 is a schematic diagram of the application scenario of the blockchain network provided by the embodiment of this application.
  • Figure 2A is an optional schematic diagram of the block structure provided by the embodiment of the present application.
  • Figure 2B is a schematic diagram of the functional architecture of the blockchain network 200 provided by the embodiment of the present application.
  • Figure 3 is a schematic structural diagram of an electronic device running a node in a blockchain network provided by an embodiment of the present application
  • FIGS 4A to 4F are schematic flow diagrams of the consensus processing method of the blockchain network provided by the embodiment of the present application.
  • FIGS 5A to 5C are flow diagrams of the consensus processing method of the blockchain network provided by the embodiment of the present application.
  • Figure 5D is a schematic diagram of the detection cycle provided by the embodiment of the present application.
  • FIG. 6 is a schematic diagram of the consensus process of the crash fault-tolerant consensus algorithm provided by the embodiment of the present application.
  • FIG. 7 is a schematic diagram of the consensus process of the Byzantine fault-tolerant consensus algorithm provided by the embodiment of the present application.
  • FIGS 8A to 8C are schematic flow charts of the blockchain consensus processing method provided by the embodiment of the present application.
  • first ⁇ second ⁇ third are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understandable that “first ⁇ second ⁇ third” is used in Where appropriate, the specific order or sequence may be interchanged so that the embodiments of the application described herein can be implemented in an order other than that illustrated or described herein.
  • Blockchain network is a system formed by multiple nodes connected through network communication; the blockchain network can also include clients.
  • the specific content of messages in the blockchain network differs according to the actual business scenario.
  • the message can be a message record, an instruction for the node's state machine to execute, etc.
  • Consensus In the blockchain network, nodes verify the correctness of messages sent by other nodes. If the verification is successful, a confirmation is sent to the node that sent the message, and the message is stored persistently to support subsequent Make message inquiries.
  • the mechanisms to achieve consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof-of-Stake (DPoS), and PoET (Proof of Elapsed). Time) etc.
  • nodes verify the validity of new blocks submitted by other nodes. If the verification is successful, a confirmation is sent to the node that submitted the new block, and the new block is added to the area stored by the corresponding node. The end of the blockchain.
  • Crash error refers to the type of error caused by the node's failure to operate normally due to node operation failure (such as node downtime); crash fault tolerance (CFT, Crash Fault tolerance) refers to the blockchain network in a certain When a number of nodes crash (for example, a node goes down), the blockchain network can still operate normally.
  • the crash fault-tolerant consensus algorithm is used as the first type of consensus algorithm. The first type of consensus algorithm can achieve higher consensus efficiency and can detect node crashes or malicious nodes or node errors, but it cannot solve the Byzantine problem.
  • Byzantine errors refer to the type of errors caused by software errors or malicious behavior of nodes; Byzantine nodes are nodes with Byzantine errors.
  • a blockchain network with a Byzantine Fault Tolerance (BFT) consensus algorithm can tolerate Byzantine errors, that is, in a distributed environment with a certain number of Byzantine nodes, the blockchain network can still operate normally.
  • BFT Byzantine Fault Tolerance
  • the Byzantine fault-tolerant consensus algorithm is used as the second type of consensus algorithm.
  • Consensus algorithm switching also called consensus algorithm adaptation
  • the block The chain network automatically adopts a consensus algorithm with high consensus efficiency and can detect wrong nodes (node crashes, malicious nodes or node errors).
  • a malicious node or node error is found (that is, when a node with a Byzantine problem is detected)
  • Alliance chain a blockchain that uses members of specific groups and limited third parties as access parties and provides services. Multiple pre-selected nodes are designated within the alliance chain as nodes that run the consensus algorithm and blockchain. Each The generation of blocks is jointly decided by all pre-selected nodes. Other access nodes do not need to participate in the process of consensus and storage of the blockchain. Other third parties can use the application programming interface (API, Application Programming Interface) opened by the blockchain. Perform limited queries on the blockchain.
  • API Application Programming Interface
  • the blockchain network involved in the embodiments of this application is formed by connecting a client and multiple nodes (any form of computing device in the access network, such as servers and user terminals) through network communication.
  • Figure 1 is an optional structural schematic diagram of a blockchain network 200 provided by an embodiment of the present application. It consists of multiple nodes 210 (any form of computing device in the access network, such as servers and user terminals) and The client 300 forms a point-to-point (P2P, Peer To Peer) network formed between the nodes 210.
  • the P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP, Transmission Control Protocol) protocol.
  • each node 210 in the blockchain network shown in Figure 1 the functions involved include:
  • Routing the basic function of nodes, is used to support communication between nodes.
  • nodes can also have the following functions:
  • Application deployed in the nodes of the blockchain network, implements specific services according to actual business needs, records messages related to the implementation of functions, carries digital signatures in the messages to indicate the source, and sends the messages to the blockchain network.
  • Other nodes allow other nodes to add messages to temporary blocks when they successfully verify the source and integrity of the message.
  • the services implemented by the application include:
  • Shared ledger is used to provide functions such as storage, query and modification of messages (carrying data).
  • the messages of the message operations are sent to other nodes in the blockchain network. After other nodes verify that they are valid, they will be recognized. Respond effectively to the message, store the message in a temporary block, and send a confirmation to the node that initiated the operation.
  • Smart contracts are computerized protocols that can execute the terms of a certain contract. They are deployed in a shared ledger and are used to implement code that is executed when certain conditions are met. The code is used to complete automated message processing based on actual business requirements. For example: check the logistics status of the goods purchased by the buyer, and transfer the buyer's payment to the merchant's account after the buyer signs for the goods.
  • Blockchain includes a series of blocks (Blocks) that follow each other in chronological order. Once a new block is added to the blockchain, it will not be removed. The blockchain network is recorded in the block. Messages submitted by the middle node.
  • FIG 2A is an optional schematic diagram of the block structure (Block Structure) provided by the embodiment of the present application.
  • Each block includes the hash value of the message record stored in this block (the hash value of this block). ), and the hash value of the previous block.
  • Each block is connected through the hash value to form a blockchain.
  • the block may also include information such as the timestamp when the block was generated.
  • Figure 2B is a schematic diagram of the functional architecture of the blockchain network 200 provided by the embodiment of the present application, including an application layer 201 and a consensus layer 202. , network layer 203, data layer 204 and resource layer 205, respectively explained below.
  • the resource layer 205 encapsulates the computing resources, storage resources and communication resources that implement each node 210 in the blockchain network 200, such as computing resources, storage resources and communication resources in computers, servers/clusters and clouds, and abstracts them to
  • the data layer 204 provides a unified interface to shield the differences in underlying hardware that implements the resource layer 205 .
  • Computing resources include various forms of processors, such as central processing units (CPUs), Application Specific Integrated Circuits (ASICs, Application Specific Integrated Circuits), ASICs, and Field Programmable Gate Arrays (FPGAs, Field-Programmable Gate Arrays).
  • processors such as central processing units (CPUs), Application Specific Integrated Circuits (ASICs, Application Specific Integrated Circuits), ASICs, and Field Programmable Gate Arrays (FPGAs, Field-Programmable Gate Arrays).
  • CPUs central processing units
  • ASICs Application Specific Integrated Circuits
  • ASICs Application Specific Integrated Circuits
  • FPGAs Field Programmable Gate Arrays
  • FPGAs Field-Programmable Gate Arrays
  • Storage resources include various types of storage media such as various volatile memories and non-volatile memories.
  • Communication resources include various links used for communication between nodes 210 of the blockchain network and between the blockchain network 200 and business entities.
  • the data layer 204 encapsulates various data structures that implement ledgers, including blockchain implemented as files in the file system, key-value state databases, and existence certificates.
  • the network layer 203 encapsulates the point-to-point (P2P, Point to Point) network protocol, data dissemination mechanism and data verification mechanism, access authentication mechanism and business subject identity management functions.
  • P2P Point to Point
  • the P2P network protocol implements communication between nodes 210 in the blockchain network 200
  • the data propagation mechanism ensures the propagation of messages in the blockchain network 200
  • the data verification mechanism is used based on cryptography methods (such as digital certificates, digital signature, public/private key pair) to achieve the reliability of data transmission between nodes 210
  • the access authentication mechanism is used to authenticate the identity of the business subject joining the blockchain network 200 according to the actual business scenario, and when the authentication is passed Grant the business subject the permission to access the blockchain network 200
  • business subject identity management is used to store the identity and permissions (such as the types of messages that can be initiated) of the business subject allowed to access the blockchain network 200.
  • the consensus layer 202 encapsulates the functions of the mechanism for the nodes 210 in the blockchain network 200 to reach consensus on blocks (i.e., the consensus mechanism), message management, and ledger management.
  • the consensus mechanism includes consensus algorithms such as POS, POW and DPOS, and supports the pluggability of the consensus algorithm.
  • Message management function used to verify the digital signature carried in the message received by the node 210, verify the identity information of the business subject, and determine whether it has the authority to send messages based on the identity information (read relevant information from the business subject identity management); For business subjects authorized to access the blockchain network 200, they all have digital certificates issued by the certification center. The business subjects use the private keys in their own digital certificates to sign the submitted messages, thereby declaring their legal identity. .
  • Ledger management function used to maintain the blockchain and state database. For the consensus-obtained block, append it to the end of the blockchain; execute the message in the consensus-obtained block, update the key-value pair in the state database when the message includes an update operation, and query the state database when the message includes a query operation. Key-value pairs and return query results to the business entity.
  • the application layer 201 encapsulates various services that the blockchain network can implement, including message traceability, certificate storage, and verification.
  • FIG. 3 is an electronic device 600 for running a node 210 of a blockchain network 200 provided by an embodiment of the present application.
  • the electronic device 600 shown in FIG. 3 includes: at least one processor 610, a memory 650, and at least one network interface 620.
  • the various components in electronic device 600 are coupled together by bus system 640 .
  • bus system 640 is used to implement connection communication between these components.
  • the bus system 640 also includes a power bus, a control bus, and a status signal bus.
  • the various buses are labeled bus system 640 in FIG. 3 .
  • the processor 610 may be an integrated circuit chip with signal processing capabilities.
  • Memory 650 may be removable, non-removable, or a combination thereof.
  • Memory 650 includes volatile memory or non-volatile memory, and may include both volatile and non-volatile memory.
  • the memory 650 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplarily described below.
  • Operating system 651 including system programs configured to process various basic system services and perform hardware-related tasks, such as framework layer, core library layer, driver layer, etc., configured to implement various basic services and process hardware-based tasks; network communication Module 652 configured to reach other computing devices via one or more (wired or wireless) network interfaces 620, example network interfaces 620 include: Bluetooth, Wireless Compliance (WiFi), and Universal Serial Bus (USB, Universal Serial Bus) etc.
  • WiFi Wireless Compliance
  • USB Universal Serial Bus
  • the consensus processing device of the blockchain network provided by the embodiment of the present application can be implemented in software.
  • Figure 2 shows the consensus processing device 655 of the blockchain network stored in the memory 650, which can be Software in the form of programs and plug-ins, including the following software modules: data collection blockchain module 6551, consensus detection blockchain module 6552, consensus switching blockchain module 6553. These modules are logical and therefore based on the functions implemented. Any combination or further split is possible. The functions of each module are explained below.
  • the blockchain network includes multiple nodes, and at least some of the multiple nodes are configured to perform consensus processing on messages sent by the client based on a consensus algorithm. After the consensus is passed, the processing results of each node's messages will be stored in the blockchain.
  • the nodes 210 in the blockchain network 200 correspond to multiple functions, among which some nodes only perform routing and blockchain functions, some nodes only perform blockchain, application and routing functions, and some nodes perform block functions. Chain, consensus and routing functions, the functions of different nodes may be different.
  • At least some nodes 210 in the blockchain network 200 may be configured to perform consensus processing on messages sent by the client based on the consensus algorithm, and the remaining nodes 210 may not perform consensus processing. .
  • Figure 4A is a schematic flow chart of the consensus processing method of the blockchain network provided by the embodiment of the present application. It will be explained in conjunction with steps 401A to 403A shown in Figure 4A, with the nodes in the blockchain network as execution The subject explains.
  • the node as the execution subject can be any node in the blockchain network, a node belonging to any access party, or a node jointly designated by multiple access parties.
  • step 401A obtain the type of consensus algorithm currently running on the blockchain network.
  • the types of consensus algorithms include the first type and the second type.
  • the consensus performance of the first type of consensus algorithm is higher than the consensus performance of the second type of consensus algorithm.
  • the fault tolerance performance of the second type of consensus algorithm is greater than that of the first type. Fault tolerance performance of consensus algorithm.
  • the blockchain network in the embodiment of this application is a consortium chain blockchain network, which can be applied in message processing scenarios.
  • the first type of consensus algorithm is a crash-fault tolerant consensus algorithm
  • the second type of consensus algorithm is a Byzantine fault-tolerant consensus algorithm.
  • the Byzantine fault-tolerant consensus algorithm has Byzantine fault tolerance, so it can prevent malicious nodes from doing evil in untrusted blockchain scenarios, thereby reaching consensus.
  • the fault-tolerant performance of Byzantine nodes is greater than the crash fault-tolerant consensus algorithm.
  • the consensus process of the crash fault-tolerant consensus algorithm includes the preparation phase and the submission phase, and each phase is a communication process between the master node and the slave node, and there is no need for interaction between the slave nodes.
  • the consensus process of the Byzantine fault-tolerant consensus algorithm includes the pre-preparation stage, the preparation stage and the submission stage. Consensus is reached through three rounds of communication processes, and slave nodes interact with each other during the communication process.
  • the communication process of the Byzantine fault-tolerant consensus algorithm is more complex than that of the crash-fault-tolerant consensus algorithm, and the consensus performance of the crash-fault-tolerant consensus algorithm is higher than that of the Byzantine fault-tolerant consensus algorithm.
  • Different types of consensus algorithms correspond to different communication processes. The type of consensus algorithm currently running can be determined based on the communication process between nodes in the blockchain network.
  • the crash fault-tolerant consensus algorithm reaches consensus on the message in the following way: Response
  • each node performs signature processing on the message; in response to the ratio of the number of normal nodes to the total number of nodes in the blockchain network being greater than or equal to the response ratio threshold (for example: 2/3), and normal If the proportion of valid consensus response messages to all consensus response messages among the consensus response messages responded by the node is greater than the valid proportion threshold (for example, 1/2), it is determined to reach consensus on the message based on the first type of consensus algorithm (collapse fault-tolerant consensus algorithm). After consensus is reached, the message and the signature of each node are stored in the block in the node.
  • the normal node is the node that responds to the message
  • the signature of the valid consensus response message is the valid signature
  • the node digitally signs the message.
  • the digital signature is a ciphertext formed by encrypting the digest of the digital content using the private key of the asymmetric encryption algorithm.
  • the digital signature is used to verify the integrity of a certain digital content. Integrity and origin (or non-repudiation).
  • the digital signature carried in the consensus response message is decoded to obtain the digital digest corresponding to the digital signature, and the digital digest is compared with the original digital digest corresponding to the message. When When the comparison results are the same, it means that the signature is valid and the consensus response message is a valid consensus response message.
  • step 402A in response to the blockchain network meeting the consensus environment detection conditions, the consensus environment detection is performed on the blockchain network and the detection results are obtained.
  • the detection result represents whether at least some nodes made an error when consensus on the message based on the consensus algorithm.
  • the consensus environment detection conditions include at least one of the following, which are described in detail below.
  • New nodes are added to the blockchain network; for example: a new access party is added to the blockchain network, and multiple electronic devices (such as terminals or servers) of the access party are added to the blockchain network. Each electronic device becomes a node, so that the new access party corresponds to multiple new nodes, and the consensus environment detection conditions are met, and the consensus environment detection is performed on the blockchain network.
  • the node load threshold is the load that the device serving as a node can bear.
  • the node may experience problems such as downtime.
  • the load of at least one node in the blockchain network exceeds the node load threshold , then the consensus environment detection conditions are met, and the consensus environment detection is performed on the blockchain network.
  • the load value of a node can be characterized by at least one of the following parameters: usage of the CPU in the node; input/output (I/O, Input/Output) throughput of the CPU in the node.
  • the access parties there are different access parties in the blockchain network.
  • the access parties can respectively correspond to multiple enterprises, banks, and message supervisors.
  • Each access direction Multiple nodes are connected to the blockchain network.
  • the node's ability to process data is limited.
  • the load of the node corresponding to the access party exceeds the load threshold corresponding to the access party, the consensus environment detection conditions are met, and the consensus environment detection is performed on the blockchain network.
  • the number of nodes corresponding to at least one network segment in the blockchain network is greater than the node load number threshold of the network segment.
  • a network segment is a part of the network that can communicate directly using the same physical layer device (transmission medium, repeater, hub, etc.).
  • Nodes in the blockchain network may use different network segments, and there are corresponding thresholds for the communication load capacity of each network segment, such as: the node load threshold of the network segment (that is, the upper limit of the number of nodes allowed to be connected to the network).
  • the node load threshold of the network segment that is, the upper limit of the number of nodes allowed to be connected to the network.
  • the corresponding detection period can also be set based on the application scenario of the blockchain network. For example, if the blockchain network is applied to the message processing scenario, the detection period T (for example: 1 minute) is set, and every other detection period Then detect and process the blocks in the current cycle in the blockchain network.
  • the detection period T for example: 1 minute
  • Step 402A can be implemented through steps 421B to 423B, which will be described in detail below.
  • step 421B the blocks generated in at least one recent detection cycle of the blockchain network are detected and processed to obtain parameters of multiple nodes.
  • the parameters include at least one of the following: the type of each node, the access party corresponding to each node, and the network segment corresponding to each node.
  • FIG. 5D is a schematic diagram of the detection cycle provided by the embodiment of the present application; the detection cycle is T, and the number of blocks generated sequentially in each detection cycle is 1, 2, 4, and 5.
  • the message processing results of the node that processed the message in at least one recent detection cycle are stored.
  • the parameters corresponding to the node can be obtained by detecting the generated blocks.
  • the types of nodes include: accounting nodes, endorsement nodes, sorting nodes, consensus nodes, etc.
  • the types of access parties corresponding to nodes include: message initiators (for example, enterprises), message processors (for example, banks), and message supervisors.
  • the detection period can be synchronized with the block generation period of the blockchain network (that is, the time required to generate a new block in the blockchain network).
  • the detection period can also be the block generation period of the blockchain network. twice or more of the value.
  • step 422B each node that performs consensus processing within at least one detection cycle is determined, the consensus response message signature of each node is verified, and the verification result of each node is obtained.
  • the verification result of a node with a correct signature of the consensus response message is a correct node
  • the verification result of a node with an incorrect signature of the consensus response message is an incorrect node
  • each node that performs consensus processing in at least one detection cycle is determined, and the consensus response message signature of each node is verified.
  • the digital signature carried in the consensus response message is decoded to obtain the digital digest corresponding to the digital signature, and the digital digest is compared with the original digital digest corresponding to the message.
  • the consensus response message signature is correct, otherwise it is incorrect.
  • step 423B the verification result of each node and at least one parameter are used as the detection result.
  • statistics can be obtained: the number of correct nodes and the number of incorrect nodes in the blockchain network, the number of consensus response messages, the number of valid consensus response messages, the access parties and areas in the blockchain network.
  • Data such as the number of nodes corresponding to each access party in the blockchain network, different network segments in the blockchain network, and the number of nodes corresponding to each network segment in the blockchain network.
  • step 403A in response to the detection result meeting the consensus algorithm switching condition corresponding to the type, the consensus algorithm currently running on the blockchain network is switched to another type of consensus algorithm.
  • different types of consensus algorithms have different consensus performance or fault tolerance.
  • different consensus algorithm switching conditions are set for different types of consensus algorithms, so that the consensus algorithm switching can be more flexible and the execution of the consensus algorithm switching can be improved. Efficiency is conducive to improving the fault tolerance and stability of the blockchain network.
  • the detection results include: the number of erroneous nodes in the blockchain network within one or more detection periods; here, the erroneous node is a node that sends an erroneous consensus response message in the blockchain network for the message. (e.g. Byzantine nodes).
  • step 403A may be implemented in the following manner: in response to the number of Byzantine nodes detected in the blockchain network within one or more continuous or interval detection periods. If it is less than or equal to the consensus proportion threshold, the second type of consensus algorithm currently running on the blockchain network will be switched to the first type of consensus algorithm.
  • the consensus ratio threshold can be 0.
  • the blockchain network is running a Byzantine fault-tolerant algorithm, and in response to no Byzantine nodes being detected for multiple consecutive detection cycles, the Byzantine fault-tolerant consensus algorithm is switched to a crash fault-tolerant consensus algorithm.
  • step 403A can be implemented through steps 431C to 433C, which will be described in detail below.
  • step 431C the proportion of error nodes is determined based on the total number of nodes and the number of error nodes in the blockchain network, and the proportion of normal nodes is determined based on the total number of nodes and the number of normal nodes.
  • the detection results include: the number of normal nodes and the number of error nodes in the blockchain network; normal nodes are nodes that do not have operating failures, and error nodes are nodes that have operating failures, such as: message errors due to malfunctions or The lost node is an error node, and the error node can be a Byzantine node.
  • step 432C in response to the proportion of erroneous nodes being equal to or greater than the global dimension fault tolerance proportion threshold corresponding to the second type of consensus algorithm, the block consensused by the erroneous nodes is rolled back.
  • the global dimension fault tolerance ratio threshold is the difference between the ratio of normal nodes and the preset fault tolerance ratio, and the preset fault tolerance ratio is 2/3.
  • master nodes can receive messages from slave nodes.
  • Normal nodes are nodes that have sent messages (normal messages, error messages) to the master node during the detection process. Let the proportion of normal nodes be P. No nodes that have sent messages to the master node (may be normal nodes or faulty nodes) have not been detected. The proportion is (1-P).
  • the blocks in this detection cycle can be rolled back, that is, in the blockchain maintained by each node Delete the blocks generated during this detection cycle.
  • step 433C the first type of consensus algorithm currently running on the blockchain network is switched to the second type of consensus algorithm.
  • step 403A can be implemented through steps 431D to 432D, which will be described in detail below.
  • step 431D the proportion of error nodes corresponding to each access party is determined based on the total number of nodes and the number of error nodes corresponding to each access party.
  • the detection results include: the number of error nodes corresponding to each access party in the blockchain network, where different access parties correspond to different nodes, and error nodes are nodes with operational failures.
  • the blockchain network includes multiple types of access parties.
  • the types of access parties include message initiators (for example: enterprises that send business messages), message processors (for example: banks that process business messages), and message supervisors (for example: The agency that oversees business messages).
  • message initiators for example: enterprises that send business messages
  • message processors for example: banks that process business messages
  • message supervisors for example: The agency that oversees business messages.
  • the number of nodes corresponding to each access party may be different.
  • step 432D in response to the proportion of error nodes corresponding to at least one access party in the blockchain network being greater than the access party dimension fault tolerance ratio threshold, the first type of consensus algorithm currently running in the blockchain network is switched to The second type of consensus algorithm.
  • the access party dimension fault tolerance ratio thresholds of different access parties can be the same or different. For example: Differentially set to different proportions according to the number of nodes corresponding to the access party. The number of at least one access party can be adjusted according to the fault tolerance requirements of specific business scenarios, for example: all access parties or some access parties in the blockchain network.
  • the proportion of erroneous nodes corresponding to at least one access party is greater than the dimensional fault tolerance ratio threshold of the access party, the blocks consensused by the erroneous nodes are rolled back, and the crash fault-tolerant consensus algorithm currently running on the blockchain network is switched to Byzantine Fault-tolerant algorithms.
  • consensus algorithm switching based on the access party dimension can improve the fault tolerance performance of the blockchain network and make the blockchain network run more stably.
  • step 403A can be implemented through steps 431E to 432E, which will be described in detail below.
  • step 431E the proportion of erroneous nodes of each type is determined based on the total number of nodes and the number of erroneous nodes of each type.
  • the corresponding detection results include: the number of error nodes of each type in the blockchain network, where error nodes are nodes with operating failures.
  • the blockchain network includes multiple types of nodes. According to the functions of the nodes, the types of nodes include: accounting nodes, endorsement nodes, sorting nodes, consensus nodes, etc. Divide the number of error nodes corresponding to each type by the total number of nodes to obtain the proportion of error nodes corresponding to each type.
  • step 432E in response to the proportion of at least one type of error nodes in the blockchain network being greater than the node dimension fault tolerance proportion threshold, the first type of consensus algorithm currently running in the blockchain network is switched to the second type of consensus. algorithm.
  • the node dimension fault tolerance ratio thresholds corresponding to different types of nodes are the same, or can be set appropriately according to the fault tolerance requirements of different accesses.
  • the number of at least one type can be adjusted according to the fault tolerance requirements of specific business scenarios, for example: all types or some types in the blockchain network.
  • the proportion of erroneous nodes corresponding to at least one type is greater than the type dimension fault tolerance ratio threshold, the blocks consensused by the erroneous nodes are rolled back, and the crash fault-tolerant consensus algorithm currently running on the blockchain network is switched to a Byzantine fault-tolerant algorithm.
  • consensus algorithm switching based on the node type dimension can improve the fault tolerance performance of the blockchain network and make the blockchain network run more stably.
  • FIG. 4F is a schematic flowchart of the consensus processing method of the blockchain network provided by the embodiment of the present application.
  • step 403A can be implemented through steps 431F to 432F, which will be described in detail below.
  • step 431F the proportion of erroneous nodes in each network segment is determined based on the total number of nodes and the number of erroneous nodes in each network segment.
  • multiple nodes in the blockchain network are located in multiple network segments; the detection results include: the number of error nodes in each network segment in the blockchain network, where the error nodes are nodes with operational failures; The number of error nodes corresponding to each network segment is divided by the total number of nodes to obtain the proportion of error nodes corresponding to each network segment.
  • step 432F in response to the proportion of error nodes in at least one network segment of the blockchain network being greater than the network segment dimension fault tolerance ratio threshold, the first type of consensus algorithm currently running on the blockchain network is switched to the second type. Consensus algorithm.
  • the network segment dimension fault tolerance ratio threshold corresponding to each network segment is determined based on the fault tolerance capability of each network segment.
  • the network segment dimension fault tolerance ratio thresholds of different network segments can be the same, or they can be differentiated. For example, they can be differentially set to different ratios based on the number of nodes corresponding to the network segment.
  • the number of at least one network segment can be adjusted according to the fault tolerance requirements of specific business scenarios, for example: all network segments or part of the network segments in the blockchain network.
  • Figure 5A is a schematic flow chart of the consensus processing method of the blockchain network provided by the embodiment of the present application.
  • the number of blocks to be rolled back before switching the consensus algorithm can also be reduced by executing step 501A, as explained in detail below.
  • step 501A in response to the existence of erroneous nodes in the blockchain network, and the proportion of erroneous nodes is less than the fault tolerance ratio threshold corresponding to the second type of consensus algorithm, the block generation speed of the blockchain network is controlled.
  • the block generation speed of the blockchain network is controlled, that is, by reducing the block generation cycle of the blockchain network (for example, adjusting it to half of the original block generation cycle or other values less than 1). Slow down the increase in block generation rate and avoid rolling back too many blocks before switching consensus algorithms.
  • the error node is a node with a running failure.
  • the types of fault tolerance ratio thresholds include:
  • the global dimension fault tolerance ratio threshold is the upper limit of the ratio of the number of faulty nodes in the blockchain network to the total number of nodes in the blockchain network;
  • the fault tolerance ratio threshold of the access party dimension is the upper limit of the ratio of the number of faulty nodes corresponding to a certain access party to the total number of nodes of the access party;
  • the node dimension fault tolerance ratio threshold is the ratio of a certain type of faulty node (such as a faulty endorsement node, a faulty accounting node, a faulty endorsement node, a faulty sorting node, a faulty consensus node) to the total number of nodes of the corresponding type. upper limit;
  • the network segment dimension fault tolerance ratio threshold that is, the upper limit of the ratio of faulty nodes in a certain network segment to the total number of nodes in the network segment.
  • step 501B can be performed to reduce the negative impact caused by consensus performance changes and fault tolerance losses when the consensus algorithm is switched.
  • step 501B the block generation speed of the blockchain network is controlled.
  • step 501A Controlling the block generation speed of the blockchain network performed in step 501A is the same as step 501B.
  • FIG. 5C is a schematic flowchart of the consensus processing method of the blockchain network provided by the embodiment of the present application.
  • Step 501B can be implemented through step 511C and step 512C, which will be described in detail below.
  • step 511C determine the block generation speed of the blockchain network in at least one historical detection period, and determine the target speed interval in which the block generation speed is located in multiple speed intervals.
  • the endpoint speeds of multiple speed intervals are connected in sequence, and multiple speed intervals can be spliced to form a continuous interval.
  • At least one historical detection cycle can be the most recent multiple or one historical detection cycles.
  • the speed interval can be determined by: obtaining the maximum block generation speed of the blockchain network, determining the speed threshold based on the maximum block generation speed and the speed ratio threshold; using zero as the first speed interval, and The interval between zero and the speed threshold is regarded as the second speed interval, the interval between greater than or equal to the speed threshold and less than the maximum block generation speed is regarded as the third speed interval, and the interval equal to the maximum block generation speed is regarded as the fourth speed interval.
  • the speed control method corresponding to the first speed interval is to control the block generation speed to maintain the minimum block generation speed.
  • the unit of the block generation speed is (number of blocks/unit time).
  • the block generation speed is The unit is (number of blocks/detection period), assuming that each detection period is 1 minute.
  • the minimum block generation speed can be 1 block per minute (1 block/min);
  • the speed control method corresponding to the second speed interval is to control the block generation speed to increase exponentially, and the block generation speed in the second speed interval is faster. Low, which avoids too many block rollbacks caused by excessive changes in the block generation speed. In message processing scenarios, it can avoid generating too many invalid messages.
  • the growth rate of the block generation speed can be higher than other intervals to ensure that the area
  • the speed control method corresponding to the third speed range is to control the block generation speed to grow at a constant speed, that is, linear growth.
  • the constant growth of the blockchain generation speed can improve the stability of the blockchain network.
  • the speed control method corresponding to the fourth speed interval is to control the block generation speed to maintain the maximum block generation speed. That is, at this time, it can be considered that the blockchain network has been able to run smoothly and maintain the maximum block generation speed.
  • the speed proportion threshold can be set to 1/2, then the speed threshold is half of the maximum block generation speed.
  • the speed interval and the speed control method corresponding to each speed interval can be expressed as the following formula (2).
  • a is a positive integer greater than 1
  • b and k are positive integers greater than or equal to 1
  • a and b can be set according to the actual needs of the blockchain network
  • k is the label of the detection period.
  • N k is the block generation speed in the current detection period.
  • N k-1 is the block generation speed corresponding to the previous detection cycle of the current detection cycle.
  • the second speed interval is (N k-1 ⁇ M/2)
  • the third speed interval is (M/2 ⁇ N k-1 ⁇ M)
  • the fourth speed interval is (N k-1 ⁇ M/2).
  • the speed interval can also be determined by: obtaining the maximum block generation speed of the blocks of the blockchain network; dividing the interval between the maximum block generation speed and zero evenly or unevenly into sequential connections. Multiple speed intervals; among them, the speed value corresponding to each speed interval is negatively related to the speed growth rate corresponding to the speed control method of each speed interval.
  • the generation speed in each interval increases at a constant speed
  • the growth rate of the block speed corresponding to each interval forms an arithmetic sequence in descending order.
  • the speed intervals and the speed control method corresponding to each speed interval can be expressed as the following formula (3).
  • c 1 and c n are positive integers
  • c 1 to c n are the growth rates of the generation speed, forming a gradually decreasing arithmetic sequence
  • d 1 and d n are positive integers
  • d 1 to d n include multiple positive Integers, forming an increasing arithmetic sequence.
  • the maximum block generation speed M is 48/min, and multiple speed intervals are generated, greater than or equal to 0 and less than 10, greater than or equal to 10 and less than 24, greater than or equal to 24 and less than 36, greater than or equal to 36 and less than 48, and equal to 48 , the generation speed increases uniformly in each interval except equal to 48.
  • the corresponding growth rates of each interval are 2, 4, 6, and 8 respectively.
  • the growth rates corresponding to each interval form an arithmetic sequence in descending order.
  • step 512C the block generation speed of the blockchain network in the current detection cycle is controlled based on the speed control method corresponding to the target speed interval.
  • the block generation speeds in each detection cycle are 1, 4/min, 8/min, 16/min...512/min (exponentially increasing in the second speed interval, and the second speed interval is greater than 0 and less than 512/min), 513, 514...1024 (the third speed interval is greater than or equal to 512/min and less than 1024/min.
  • the block generation speed reaches 1024/min, that is, the fourth Speed range, the block generation speed remains unchanged at 1024/min).
  • the consensus processing method of the blockchain network enables the blockchain network to switch to a crash fault-tolerant consensus when there are no Byzantine nodes in the network environment, thereby meeting application scenarios with high performance requirements; when an area is detected
  • the consensus algorithm is switched to a Byzantine fault-tolerant consensus to provide better fault tolerance. Controlling the block generation speed after the consensus algorithm is switched can reduce the negative impact caused by changes in consensus performance and fault tolerance losses when the consensus algorithm is switched.
  • the consensus algorithm can be adaptively switched according to changes in business scenarios, which can not only provide better fault tolerance but also meet the needs of application scenarios with high performance requirements.
  • FIG. 6 is a schematic diagram of the consensus process of the crash fault-tolerant consensus algorithm provided by the embodiment of the present application.
  • the consensus process of the Recursive Algorithm for Fault Tolerance (RAFT, Recursive Algorithm for Fault Tolerance) in the crash fault tolerance category is used as an example to illustrate.
  • the consensus process can be abstracted into the preparation phase and the submission phase.
  • the master node C1 receives the client K1 After the message, it enters the preparation stage, and the master node synchronizes the log records to the slave nodes (slave node C2, slave node C3 and slave node C4).
  • the slave node After receiving the message, the slave node sends a response to the master node C1, and the master node C1 receives the message. After more than half of the responses are received, the submission phase is entered.
  • the master node C1 sends a message to the slave node, submits the data, and returns the result to the client K1.
  • Raft's consensus process consists of two stages, and each stage only includes the communication process between the master node and the slave node. There is no need for interaction between the slave nodes.
  • the overall communication complexity is O(n), where n is the number of nodes. Therefore, crash fault-tolerant consensus algorithms represented by Raft usually have higher throughput, so the overall system can achieve higher performance.
  • the maximum number of crash error nodes that the crash fault-tolerant consensus can tolerate is (n-1)/2, where n is a positive integer greater than or equal to 1.
  • FIG 7 is a schematic diagram of the consensus process of the Byzantine fault-tolerant consensus algorithm provided by the embodiment of the present application.
  • the Byzantine Fault Tolerance consensus algorithm usually requires three rounds of communication processes to reach consensus.
  • the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm in the Byzantine Fault Tolerance category is used as an example to illustrate.
  • the master node B1 receives the client After the request from terminal K2, it enters the pre-preparation stage. Master node B1 sends messages to all slave nodes (slave node B2, slave node B3, slave node B4). The slave node receives the message and checks it (for example, verifying the signature, etc.).
  • PBFT Practical Byzantine Fault Tolerance
  • each node After the check is correct, enter the preparation stage; after each node encapsulates the message (such as signature and other operations), it further broadcasts it to other nodes.
  • the correct message received by the node is greater than or equal to 2f+1 (including the node itself), where f is greater than A positive integer equal to 1, enters the submission phase; each node encapsulates the message and broadcasts it to other nodes.
  • the correct submission message received is greater than or equal to 2f+1 (including the node itself)
  • a consensus is reached, and the data is submitted.
  • a response request message is sent to the client.
  • the system can still reach consensus when there is 1 Byzantine node.
  • the embodiment of this application provides a blockchain consensus processing method that can adaptively switch different consensus algorithms according to changes in the operating environment, involving switching between Byzantine fault-tolerant consensus algorithms and crash fault-tolerant consensus algorithms.
  • the crash fault-tolerant consensus algorithm uses the following methods to reach consensus: in response to the message being delivered to each node, each node performs signature processing on the message; in response to the number of normal nodes in the blockchain network accounting for the total nodes
  • the proportion of the quantity is greater than or equal to the response proportion threshold (for example: 2/3), and the proportion of valid consensus response messages to all consensus response messages among the consensus response messages responded by normal nodes is greater than the effective proportion threshold (for example, 1/2), determined Consensus is reached on messages based on the first type of consensus algorithm.
  • Figure 8A is a schematic flow chart of the blockchain consensus processing method provided by the embodiment of the present application, which will be described in detail below.
  • step 801A the consensus environment is detected.
  • the indicator detected in the consensus environment detection is the number of Byzantine nodes in the current system operating environment.
  • the detection method is to verify the consensus message signature of each node in the block: if the node verification is successful, it means that the node does not have a Byzantine error; if the node verification fails, it means that a Byzantine error or other errors have occurred.
  • FIG. 5D is a schematic diagram of the detection cycle provided by the embodiment of the present application; the consensus environment detection is performed every unit time T, as shown in Figure 5D.
  • the time T can be set according to different business scenarios. For example, in scenarios that require frequent detection, you can set a smaller T value. For example, in a scenario where business-related messages are processed, set T to a preset number of seconds (for example, 5 seconds) to check frequently, or set T to a predetermined number of seconds. Set minutes (eg 1 minute).
  • the scope of each detection is the blocks generated within the current unit time T (i.e., the detection period mentioned above).
  • the number of blocks generated within the unit time T (for example, 1 minute) is determined by the switching transition strategy (i.e., this application
  • the process of controlling the block generation speed in the embodiment is determined.
  • step 802A it is determined whether the consensus switching condition is met. When the judgment result of step 802A is yes, step 803A is executed; if not, step 801A is continued.
  • the consensus switching condition is: no Byzantine errors occur in multiple consecutive consensus environment tests (that is, the number of Byzantine nodes is 0). Meeting the consensus switching conditions indicates that the nodes in the operating environment are trustworthy at this time. At this time, switching the Byzantine fault-tolerant algorithm to the crash fault-tolerant algorithm can improve system performance.
  • the specific number of detections can be customized according to the business scenario. If more reliable fault tolerance is required, a larger number can be set.
  • step 803A the consensus algorithm is switched.
  • switching the consensus algorithm means switching the current consensus algorithm to a crash fault-tolerant algorithm.
  • step 804A a handover transition policy is applied.
  • the switching transition strategy is used to control the speed of block generation after the consensus algorithm is switched to prevent system crashes or excessive block rollback.
  • Step 804A may be implemented through steps 801C to 806C.
  • step 801C it is determined that the consensus algorithm switching is completed.
  • step 802C the number of blocks generated in a single consensus round is increased exponentially.
  • the embodiment of this application takes the block generation speed as zero after the consensus algorithm switch is completed.
  • the switching transition strategy controls the generation speed of blocks by limiting the number of blocks generated within unit time T.
  • Unit time T is the detection period for performing consensus detection above.
  • the block generation speed can be characterized as the number of blocks generated per unit time. Assume that each unit time T is a consensus detection round (each consensus detection round corresponds to one consensus detection), use N to represent the number of blocks generated by each consensus detection round, and the kth consensus detection round generates The number of blocks is N k , and k is greater than or equal to 1. Each time the transition strategy is applied, the accumulated consensus detection rounds will be restarted.
  • the system generates a single consensus detection round under the current consensus algorithm.
  • the maximum number of blocks is M.
  • the calculation method of N k is as shown in the following formula (1).
  • slow block generation corresponds to step 802C, when the number of blocks generated in a single consensus detection round (time T) When less than M/2 (the block generation speed is small, that is, the number of blocks generated within time T is small), the blocks generated in each consensus detection round are controlled to grow exponentially (that is, the block generation speed growing exponentially).
  • step 803C it is determined whether the number of blocks generated in a single round is less than M/2. When the judgment result is yes, step 802C is executed; if not, step 804C is executed.
  • the block generation speed increases at a high rate, but the number of blocks in a single consensus detection round is small. If a consensus switch occurs at this time, a rollback is required.
  • the number of blocks is also relatively small, which can avoid generating too many invalid messages in message processing scenarios.
  • maintaining a low block generation rate after the switch can also prevent system crashes caused by nodes being unable to handle a large number of requests.
  • step 804C the number of blocks generated in a single consensus round is increased linearly.
  • step 805C it is determined whether the number of blocks generated in a single round is less than M. When the judgment result is yes, step 804C is executed; if not, step 806C is executed.
  • step 806C the number of blocks generated in a single round is maintained at M, and the system runs smoothly.
  • the number of blocks generated by each round of consensus is, in order, 1, 4, 8, 16...512 (1 to 512 grows exponentially), 513, 514...1024 (513 to 1024 Grows at a constant rate, and when it reaches 1024, it remains unchanged at 1024).
  • Figure 8B is a schematic flow chart of the blockchain consensus processing method provided by the embodiment of the present application, which will be described in detail below.
  • step 801B the consensus environment is detected.
  • step 801B may refer to step 801A.
  • step 802B it is determined whether the consensus switching condition is met. When the judgment result is yes, step 803C is executed. When the judgment result is no, step 804C is executed.
  • the consensus switching condition corresponding to the crash fault-tolerant algorithm is: the proportion of Byzantine nodes detected in a certain consensus process is greater than Then the consensus algorithm is switched.
  • P is the ratio between the number of messages received by the master node from different nodes during the consensus process and the total number of nodes. Assume that the (1-P) nodes that have not received the message from the other nodes are all Byzantine nodes. If the Byzantine nodes detected during a certain consensus process are greater than Then the total proportion of Byzantine nodes in the network will be greater than That is greater than Indicates that there may be a number of Byzantine nodes that cannot be tolerated by the Byzantine fault-tolerant consensus.
  • step 803B the consensus algorithm is switched.
  • step 804B whether there is a Byzantine error in the current round.
  • step 805B is executed; if not, step 801B is executed.
  • a switching transition strategy will be implemented to slow down the generation speed of blocks and avoid rolling back too many blocks when switching consensus algorithms.
  • step 805B the handover transition policy is applied.
  • step 805B can also be implemented through steps 801C to 806C, which will not be described again here.
  • User A, User B, and User C are performing federated learning tasks for the item recommendation model.
  • User A has the first part of the training data for the item recommendation model
  • User B has the second part of the training data for the item recommendation model
  • User C has the data for the item recommendation model.
  • the third part of training data of the item recommendation model, wherein the first part of training data, the second part of training data and the third part of training data constitute complete training data configured to train the item recommendation model.
  • user A initiates a request to the blockchain network to train the item recommendation model based on the first part of the training data through the terminal device (the client running the blockchain network), and user B uses the terminal device (running the blockchain network) The client) initiates a request to the blockchain network to train the item recommendation model based on the second part of the training data.
  • User C initiates the training based on the first part to the blockchain network through the terminal device (the client running the blockchain network). Request for data training of item recommendation model.
  • the nodes in the blockchain network act as training equipment. Through the above training data, combined with the federated learning algorithm, the item recommendation model is trained. During the training process, messages carrying the parameters of the item recommendation model of each node need to pass The consensus algorithm obtains unanimous approval from other nodes and then is configured to update the item recommendation model, which ensures the reliability of model updates.
  • Nodes in the blockchain network adopt the first type of consensus algorithm by default to achieve higher consensus performance than the second consensus algorithm.
  • each node will also conduct consensus environment detection. If the detection results indicate that at least some nodes have made errors when consensus on messages based on the consensus algorithm, it means that unstable factors have been introduced into the blockchain network (such as network communication quality jitter, If a malicious node is added, etc.), it will switch to the second consensus algorithm. Since the fault tolerance of the second consensus algorithm is higher than that of the first consensus algorithm, it can ensure reliable consensus on the parameters of the item recommendation model and avoid introducing it into the item recommendation model. Wrong parameters ensure accurate and reliable updates of the item recommendation model.
  • the consensus processing method of the blockchain network enables the blockchain network to switch to a crash fault-tolerant consensus when there are no Byzantine nodes in the network environment, thereby meeting application scenarios with high performance requirements; when the system detects When there are a certain number of Byzantine nodes in the system, the consensus algorithm is switched to a Byzantine fault-tolerant consensus to provide better fault tolerance.
  • the switching transition strategy provided by this application can reduce the negative impact caused by consensus performance changes and fault tolerance losses when the consensus algorithm is switched.
  • the consensus algorithm can be adaptively switched according to changes in business scenarios, which can not only provide better fault tolerance but also meet the needs of application scenarios with high performance requirements.
  • the blockchain network includes multiple nodes. At least some of the nodes are configured to perform consensus processing on messages sent by the client based on a consensus algorithm; the software module stored in the consensus processing device 655 of the blockchain network in the memory 650 may include: a data collection blockchain module 6551, Configured to obtain the type of consensus algorithm currently running on the blockchain network; the consensus detection blockchain module 6552 is configured to perform consensus environment detection on the blockchain network in response to the blockchain network meeting the consensus environment detection conditions, and obtain the detection As a result, the detection result represents whether at least some nodes made an error when consensus on the message based on the consensus algorithm; the consensus switching blockchain module 6553 is configured to respond to the detection result satisfying the consensus algorithm switching condition corresponding to the type, and change the current status of the blockchain network to The running consensus algorithm is switched to other types of consensus algorithms; among them, the types of consensus algorithms include the
  • the detection results include: the number of error nodes in the blockchain network within one or more detection periods; wherein the error nodes are for messages A node that sent an erroneous consensus response message; the consensus switching blockchain module 6553 is configured to respond to the number of erroneous nodes detected in the blockchain network being less than or equal to the consensus ratio threshold within one or more detection periods.
  • the second type of consensus algorithm currently running on the blockchain network is switched to the first type of consensus algorithm.
  • the detection results include: the number of normal nodes and the number of error nodes in the blockchain network; where normal nodes are nodes that do not have operational failures. , the error node is a node with operational failure; the consensus switching blockchain module 6553 is configured to determine the proportion of error nodes based on the total number of nodes and the number of error nodes in the blockchain network, based on the total number of nodes and the number of normal nodes , determine the proportion of normal nodes; in response to the proportion of erroneous nodes being equal to or greater than the global dimension fault tolerance proportion threshold corresponding to the second type of consensus algorithm, perform rollback processing on the block consensused by the erroneous node, where the global dimension fault tolerance proportion threshold is The difference between the proportion of normal nodes and the preset fault tolerance ratio; switching the first type of consensus algorithm currently running on the blockchain network to the second type of consensus algorithm.
  • the detection results include: the number of error nodes corresponding to each access party in the blockchain network, where different access parties correspond to For different nodes, the error node is a node with operating failure; the consensus switching blockchain module 6553 is configured to determine the error corresponding to each access party based on the total number of nodes and the number of error nodes corresponding to each access party.
  • the proportion of nodes in response to the proportion of erroneous nodes corresponding to at least one access party in the blockchain network being greater than the access party dimension fault tolerance proportion threshold, switch the first type of consensus algorithm currently running in the blockchain network to the third Two types of consensus algorithms.
  • multiple nodes belong to multiple types respectively; when the blockchain network runs the consensus algorithm of the first type, the detection results include: the number of error nodes of each type in the blockchain network, where error The node is a node with operational failure; the consensus switching blockchain module 6553 is configured to determine the proportion of error nodes of each type based on the total number of nodes and the number of error nodes of each type; in response to at least If the proportion of one type of faulty nodes is greater than the node dimension fault tolerance ratio threshold, the first type of consensus algorithm currently running on the blockchain network will be switched to the second type of consensus algorithm.
  • multiple nodes in the blockchain network are located in multiple network segments; the detection results include: the number of error nodes in each network segment in the blockchain network, where the error nodes have operational failures.
  • Node when the blockchain network runs the first type of consensus algorithm, the consensus switching blockchain module 6553 is configured to determine the error nodes of each network segment based on the total number of nodes and the number of error nodes in each network segment. proportion; in response to the proportion of erroneous nodes in at least one network segment of the blockchain network being greater than the network segment dimension fault tolerance proportion threshold, switch the first type of consensus algorithm currently running on the blockchain network to the second type of consensus algorithm .
  • the consensus switching blockchain module 6553 when the blockchain network runs the first type of consensus algorithm, the consensus switching blockchain module 6553 is configured to respond to the presence of erroneous nodes in the blockchain network, and the proportion of erroneous nodes is smaller than that of the second type.
  • the fault tolerance ratio threshold corresponding to the consensus algorithm controls the block generation speed of the blockchain network; among them, the error node is a node with a running failure.
  • the types of fault tolerance ratio thresholds include: global dimension fault tolerance ratio threshold, access party dimension Fault tolerance ratio threshold, node dimension fault tolerance ratio threshold, and network segment dimension fault tolerance ratio threshold.
  • the consensus switching blockchain module 6553 is configured to control the block generation speed of the blockchain network.
  • the consensus switching blockchain module 6553 is configured to determine the block generation speed of the blockchain network in at least one historical detection period, and determine the target of the block generation speed in a plurality of speed intervals. Speed interval, in which the endpoint speeds of multiple speed intervals are connected in sequence; based on the speed control method corresponding to the target speed interval, the block generation speed of the blockchain network in the current detection cycle is controlled, where different speed intervals correspond to The speed control methods are different.
  • the consensus switching blockchain module 6553 is configured to obtain the maximum block generation speed of the blockchain network, determine the speed threshold based on the maximum block generation speed and the speed ratio threshold; use zero as the first speed interval, The interval between zero and the speed threshold is regarded as the second speed interval, the interval greater than or equal to the speed threshold and less than the maximum block generation speed is regarded as the third speed interval, and the interval equal to the maximum block generation speed is regarded as the fourth speed interval; where, The speed control method corresponding to the first speed interval is to control the block generation speed to maintain the minimum block generation speed.
  • the speed control method corresponding to the second speed interval is to control the block generation speed to increase exponentially.
  • the speed control method corresponding to the third speed interval is The method is to control the block generation speed to increase at a constant speed.
  • the speed control method corresponding to the fourth speed interval is to control the block generation speed to maintain the maximum block generation speed unchanged.
  • the consensus switching blockchain module 6553 is configured to obtain the maximum block generation speed of the blocks of the blockchain network; divide the interval between the maximum block generation speed and zero into a plurality of sequentially connected Speed interval; among them, the speed value corresponding to each speed interval is negatively related to the speed growth rate corresponding to the speed control method of each speed interval.
  • the consensus switching blockchain module 6552 is configured to detect and process blocks generated in at least one recent detection cycle of the blockchain network to obtain parameters of multiple nodes, where the parameters include at least one of the following: 1: The type of each node, the access party corresponding to each node, and the network segment corresponding to each node; determine each node that performs consensus processing within at least one detection cycle, and verify the consensus response message signature of each node. Verification processing is performed to obtain the verification results of each node. Among them, the verification results of nodes with correct consensus response message signatures are correct nodes, and the verification results of nodes with incorrect consensus response message signatures are incorrect nodes; the verification results of each node are The test results and at least one parameter are taken as the test results.
  • the consensus environment detection conditions include at least one of the following: new nodes are connected to the blockchain network; the load of at least one node in the blockchain network exceeds the node load threshold; at least one node is connected to the blockchain network The load corresponding to the party exceeds the load threshold; the number of nodes corresponding to at least one network segment in the blockchain network is greater than the node load number threshold of the network segment.
  • the consensus detection blockchain module 6552 is configured to perform signature processing on the message in response to the message being delivered to each node; in response to the proportion of the number of normal nodes to the total number of nodes in the blockchain network being greater than or is equal to the response proportion threshold, and the proportion of effective consensus response messages in the consensus response messages of normal nodes is greater than the effective proportion threshold, it is determined to reach consensus on the message based on the first type of consensus algorithm, where the normal node is the node that responds to the message, The signature of a valid consensus response message is a valid signature.
  • Embodiments of the present application provide a computer program product or computer program.
  • the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the consensus processing method of the blockchain network described above in the embodiment of the present application.
  • Embodiments of the present application provide a computer-readable storage medium storing executable instructions.
  • the executable instructions are stored therein.
  • the executable instructions When executed by a processor, they will cause the processor to execute the blockchain provided by the embodiments of the present application.
  • the consensus processing method of the network is, for example, the consensus processing method of the blockchain network as shown in any of the figures of Figure 4A to Figure 4F and Figure 5A to Figure 5C.
  • the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; it may also include one or any combination of the above memories.
  • Various equipment may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; it may also include one or any combination of the above memories.
  • Various equipment may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; it may also include one or any combination of the above memories.
  • executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and their May be deployed in any form, including deployed as a stand-alone program or deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • executable instructions may be deployed to execute on one computing device, or on multiple computing devices located at one location, or alternatively, on multiple computing devices distributed across multiple locations and interconnected by a communications network execute on.
  • the consensus algorithm switching of the blockchain network is performed based on the consensus detection results and the switching conditions corresponding to the consensus algorithm, so that the consensus algorithm switching of the blockchain network is more efficient.
  • the consensus algorithm can be adaptively switched according to changes in business scenarios, which can not only provide better fault tolerance but also meet the needs of application scenarios with high performance requirements.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Environmental & Geological Engineering (AREA)
  • Algebra (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种区块链网络的共识处理方法、装置、设备及存储介质、程序产品；方法包括：获取区块链网络当前所运行的共识算法的类型；响应于区块链网络满足共识环境检测条件，对区块链网络进行共识环境检测，得到检测结果，其中，检测结果表征至少部分节点基于共识算法对消息进行共识时是否出错；响应于检测结果满足类型对应的共识算法切换条件，将区块链网络当前所运行的共识算法切换为其他类型的共识算法；共识算法的类型包括第一类型与第二类型，第一类型的共识算法的容错性能大于第二类型的共识算法的容错性能，第二类型的共识算法的共识性能高于第一类型的共识算法的共识性能。

Description

区块链网络的共识处理方法、装置、设备及存储介质、程序产品
相关申请的交叉引用
本申请基于申请号为202210302668.6、申请日为2022年3月24日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及区块链技术，尤其涉及一种区块链网络的共识处理方法、装置、设备及存储介质、程序产品。
背景技术
相关技术中，区块链网络目前采用的共识算法往往侧重于达成共识的效率，而对节点异常的容错形能有限，或仅关注在达成共识的过程中的容错性能，容错性能是指存在故障节点或恶意节点时，保证多数的节点仍然能够达成共识。相关技术中，区块链网络中的共识算法切换灵活性不高，影响了区块链网络的容错性能。
发明内容
本申请实施例提供一种区块链网络的共识处理方法、装置、设备及计算机可读存储介质、计算机程序产品，能够提升区块链网络的容错性能。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种区块链网络的共识处理方法，由电子设备执行，电子设备中运行所述区块链网络包括的多个节点，所述多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识处理；
所述方法包括：
获取所述区块链网络当前所运行的所述共识算法的类型；
响应于所述区块链网络满足共识环境检测条件，对所述区块链网络进行共识环境检测，得到检测结果，其中，所述检测结果表征所述至少部分节点基于所述共识算法对所述消息进行共识时是否出错；
响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法；
其中，所述共识算法的类型包括第一类型与第二类型，所述第一类型的共识算法的共识性能高于所述第二类型的共识算法的共识性能，所述第二类型的共识算法的容错性能大于所述第一类型的共识算法的容错性能。
本申请实施例提供一种区块链网络的共识处理装置，所述区块链网络包括多个节点，所述多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识处理，所述装置包括：
数据采集区块链模块，配置为获取所述区块链网络当前所运行的所述共识算法的类型；
共识检测区块链模块，配置为响应于所述区块链网络满足共识环境检测条件，对所述区块链网络进行共识环境检测，得到检测结果，其中，所述检测结果表征所述至少部分节点基于所述共识算法对所述消息进行共识时是否出错；
共识切换区块链模块，配置为响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法；
其中，所述共识算法的类型包括第一类型与第二类型，所述第一类型的共识算法的共识性能高于所述第二类型的共识算法的共识性能，所述第二类型的共识算法的容错性能大于所述第一类型的共识算法的容错性能。
本申请实施例提供一种电子设备，所述电子设备包括：
存储器，用于存储可执行指令；
处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的区块链网络的共识处理方法。
本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的区块链网络的共识处理方法。
本申请实施例提供一种计算机程序产品，包括计算机程序或指令，所述计算机程序或指令被处理器执行时实现本申请实施例提供的区块链网络的共识方法。
本申请实施例具有以下有益效果：
在满足共识环境检测条件时，基于共识检测结果与共识算法对应的切换条件对区块链网络进行共识算法切换，使得区块链网络的共识算法切换更灵活，更符合区块链网络的容错需求，提升区块链网络的容错能力以及运行的稳定性。进而，区块链网络能够根据业务场景的变化自适应地切换共识算法，能满足不同的应用场景需求。
附图说明
图1是本申请实施例提供的区块链网络的应用场景的示意图；
图2A是本申请实施例提供的区块结构一个可选的示意图
图2B是本申请实施例提供的区块链网络200的功能架构示意图；
图3是本申请实施例提供的运行区块链网络中的节点的电子设备的结构示意图；
图4A至图4F是本申请实施例提供的区块链网络的共识处理方法的流程示意图；
图5A至图5C是本申请实施例提供的区块链网络的共识处理方法的流程示意图；
图5D是本申请实施例提供的检测周期的示意图；
图6是本申请实施例提供的崩溃容错类的共识算法的共识过程示意图；
图7是本申请实施例提供的拜占庭容错类的共识算法的共识过程示意图；
图8A至8C是本申请实施例提供的区块链的共识处理方法的流程示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表 针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
需要指出，在本申请实施例中，涉及到用户的信息、用户的反馈数据等相关的数据，当本申请实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)区块链网络，由多个节点通过网络通信而连接形成的系统；区块链网络还可以包括客户端。区块链网络中消息的具体内容根据实际的业务场景而有区别，例如，消息可以为消息记录、供节点的状态机执行的指令等。
2)共识，在区块链网络中，节点对其他节点发送的消息的正确性进行验证，如验证成功则向发送消息的节点发送确认，并将该消息进行持久化存储，以用于支持后续进行消息查询。实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Proof of Stake)、股份授权证明(DPoS，Delegated Proof-of-Stake)、消逝时间量证明(PoET，Proof of Elapsed Time)等。
例如，在区块链网络中，节点对其他节点提交的新区块的有效性进行验证，如验证成功，则向提交新区块的节点发送确认，并将该新区块添加到相应节点所存储的区块链的尾部。
3)崩溃错误(故障容错)，指由于节点的运行故障(例如节点宕机)而使得节点无法正常运行所导致的错误类型；崩溃容错(CFT，Crash Fault tolerance)是指区块链网络在一定数量的节点崩溃(例如，节点宕机)时，区块链网络仍能正常运行。本申请实施例中，将崩溃容错共识算法作为第一类型的共识算法。第一类型的共识算法下，能够实现较高的共识效率、并且能够检测到节点崩溃或者恶意节点、节点错误，但是无法解决拜占庭问题。
4)拜占庭错误，指软件错误或节点的恶意行为所导致的错误类型；拜占庭节点是存在拜占庭错误的节点。在分布式环境中，具有拜占庭容错(BFT，Byzantine Fault Tolerance)共识算法的区块链网络能够容忍拜占庭错误，即在存在一定数量的拜占庭节点的分布式环境中，区块链网络仍能正常运行。本申请实施例中，将拜占庭容错共识算法作为第二类型的共识算法。
4)共识算法切换，也称为共识算法自适应，当网络环境良好(例如没有恶意节点或者节点错误，或者，恶意节点或者节点错误的数量的低于设定的门限值)时，区块链网络自动采用共识效率高、可以检测到错误节点(节点崩溃、恶意节点或者节点错误)的共识算法，当发现恶意节点或者节点错误的时候(也即，检测到存在拜占庭问题的节点时)，可以自动切换到支持解决拜占庭容错的共识算法。
5)联盟链，将特定群体的成员和有限的第三方作为接入方，并提供服务的区块链，联盟链内部指定多个预选的节点为运行共识算法和区块链的节点，每个区块的生成由所有的预选节点共同决定，其他接入节点可以不参与共识和存储区块链的过程，其他第三方可以通过该区块链开放的应用程序编程接口(API，Application Programming Interface)对区块链进行限定查询。
本申请实施例涉及的区块链网络是由客户端、多个节点(接入网络中的任意形式的 计算设备，如服务器、用户终端)通过网络通信的形式连接形成。
参见图1，图1是本申请实施例提供的区块链网络200的一个可选的结构示意图，由多个节点210(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端300形成，节点210之间形成组成的点对点(P2P，Peer To Peer)网络，P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。
参见图1示出的区块链网络中各节点210的功能，涉及的功能包括：
1)路由，节点具有的基本功能，用于支持节点之间的通信。
节点除具有路由功能外，还可以具有以下功能：
2)应用，部署在区块链网络的节点中，根据实际业务需求而实现特定业务，记录实现功能相关的消息，在消息中携带数字签名以表示来源，将消息发送到区块链网络中的其他节点，供其他节点在验证消息来源以及完整性成功时，将消息添加到临时区块中。
例如，应用实现的业务包括：
2.1)共享账本，用于提供消息(携带数据)的存储、查询和修改等操作的功能，将对消息的操作的消息发送到区块链网络中的其他节点，其他节点验证有效后，作为承认消息有效的响应，将消息存入临时区块中，还可以向发起操作的节点发送确认。
2.2)智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本，用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的消息处理，例如：查询买家所购买商品的物流状态，在买家签收货物后将买家的货款转移到商户的账户。
3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链网络中节点提交的消息。
参见图2A，图2A是本申请实施例提供的区块结构(Block Structure)一个可选的示意图，每个区块中包括本区块存储消息记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。
下面说明本申请实施例提供的区块链网络的示例性的功能架构，参见图2B，图2B是本申请实施例提供的区块链网络200的功能架构示意图，包括应用层201、共识层202、网络层203、数据层204和资源层205，下面分别进行说明。
资源层205封装了实现区块链网路200中的各个节点210的计算资源、存储资源和通信资源，例如计算机、服务器/集群和云中的计算资源、存储资源和通信资源，进行抽象并向数据层204提供统一的接口以屏蔽实现资源层205的底层硬件的差异性。
计算资源包括各种形式的处理器，例如中央处理器(CPU)、应用专用集成电路(ASIC，Application Specific Integrated Circuit)、专用集成电路和现场可编程门阵列(FPGA，Field-Programmable Gate Array)的各种形式的处理器。
存储资源包括各种易失性存储器和非易失性存储器等各种类型的存储介质。通信资源包括用于供区块链网络的节点210之间、区块链网络200与业务主体之间通信的各种链路。
数据层204封装了实现账本的各种数据结构，包括以文件系统中的文件实现的区块链，键值型的状态数据库和存在性证明。
网络层203封装了点对点(P2P，Point to Point)网络协议、数据传播机制和数据验证机制、接入认证机制和业务主体身份管理的功能。
其中，P2P网络协议实现区块链网络200中节点210之间的通信，数据传播机制保证了消息在区块链网络200中的传播，数据验证机制用于基于加密学方法(例如数字证书、数字签名、公/私钥对)实现节点210之间传输数据的可靠性；接入认证机制用于根 据实际的业务场景对加入区块链网络200的业务主体的身份进行认证，并在认证通过时赋予业务主体接入区块链网络200的权限；业务主体身份管理用于存储允许接入区块链网络200的业务主体的身份、以及权限(例如能够发起的消息的类型)。
共识层202封装了区块链网络200中的节点210对区块达成一致性的机制(即共识机制)、消息管理和账本管理的功能。
共识机制包括POS、POW和DPOS等共识算法，支持共识算法的可插拔。
消息管理功能：用于验证节点210接收到的消息中携带的数字签名，验证业务主体的身份信息，并根据身份信息判断确认其是否具有权限发送消息(从业务主体身份管理读取相关信息)；对于获得接入区块链网络200的授权的业务主体而言，均拥有认证中心颁发的数字证书，业务主体利用自己的数字证书中的私钥对提交的消息进行签名，从而声明自己的合法身份。
账本管理功能：用于维护区块链和状态数据库。对于取得共识的区块，追加到区块链的尾部；执行取得共识的区块中的消息，当消息包括更新操作时更新状态数据库中的键值对，当消息包括查询操作时查询状态数据库中的键值对并向业务主体返回查询结果。支持对状态数据库的多种维度的查询操作，包括：根据区块序列号(例如消息的哈希值)查询区块；根据区块哈希值查询区块；根据消息序列号查询区块；根据消息序列号查询消息；根据业务主体的账号(序列号)查询业务主体的账号数据；根据通道名称查询通道中的区块链。
应用层201封装了区块链网络能够实现的各种业务，包括消息的溯源、存证和验证等。
下面说明本申请实施例提供的运行区块链网络的节点的电子设备的示例性结构，参见图3，图3是本申请实施例提供的运行区块链网络200中的节点210的电子设备600的结构示意图，电子设备可以是终端(例如PC)、服务器或服务器集群，电子设备供区块链网络200中的节点210运行的虚拟化环境，并提供节点210的运行的资源(包括计算资源、存储资源和通信资源)。图3所示的电子设备600包括：至少一个处理器610、存储器650和至少一个网络接口620。电子设备600中的各个组件通过总线系统640耦合在一起。可理解，总线系统640用于实现这些组件之间的连接通信。总线系统640除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统640。
处理器610可以是一种集成电路芯片，具有信号的处理能力。存储器650可以是可移除的，不可移除的或其组合。存储器650包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。在一些实施例中，存储器650能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
操作系统651，包括配置为处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，配置为实现各种基础业务以及处理基于硬件的任务；网络通信模块652，配置为经由一个或多个(有线或无线)网络接口620到达其他计算设备，示例性的网络接口620包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等。
在一些实施例中，本申请实施例提供的区块链网络的共识处理装置可以采用软件方式实现，图2示出了存储在存储器650中的区块链网络的共识处理装置655，其可以是程序和插件等形式的软件，包括以下软件模块：数据采集区块链模块6551、共识检测区块链模块6552、共识切换区块链模块6553，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
将结合本申请实施例提供的区块链网络的示例性应用和实施，说明本申请实施例提供的区块链网络的共识处理方法。
本申请实施例中，区块链网络包括多个节点，多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识处理。共识通过之后，每个节点对于消息的处理结果将被存储到区块链中。参考图1，区块链网络200中的节点210对应于多种功能，其中，部分节点仅执行路由与区块链功能，部分节点仅执行区块链、应用以及路由功能，部分节点执行区块链、共识以及路由功能，不同节点的功能可以是不同的，区块链网络200中至少部分节点210可以配置为基于共识算法对客户端发送的消息进行共识处理，其余节点210可以不执行共识处理。
参见图4A，图4A是本申请实施例提供的区块链网络的共识处理方法的流程示意图，将结合图4A示出的步骤401A至步骤403A进行说明，以区块链网络中的节点为执行主体进行说明。
示例的，作为执行主体的节点可以是区块链网络中任意节点，可以是属于任意接入方的节点，也可以是多个接入方共同指定的节点。
在步骤401A中，获取区块链网络当前所运行的共识算法的类型。
这里，共识算法的类型包括第一类型与第二类型，第一类型的共识算法的共识性能高于第二类型的共识算法的共识性能，第二类型的共识算法的容错性能大于第一类型的共识算法的容错性能。
示例的，本申请实施例中区块链网络是联盟链区块链网络，可以应用在消息处理场景中。第一类型的共识算法是崩溃容错共识算法，第二类型的共识算法是拜占庭容错共识算法。拜占庭容错共识算法具有拜占庭容错能力，因而能够在不可信的区块链场景中防止恶意节点作恶，从而达成共识，对于拜占庭节点的容错性能大于崩溃容错共识算法。
崩溃容错共识算法的共识过程包括准备阶段与提交阶段，且每个阶段均为主节点与从节点之间的通信过程，从节点之间无需进行交互。拜占庭容错共识算法的共识过程包括预准备阶段、准备阶段以及提交阶段，通过三轮通信过程达成共识，通信过程中从节点之间进行交互。拜占庭容错共识算法的通信过程相较于崩溃容错共识算法更复杂，崩溃容错共识算法的共识性能高于拜占庭容错共识算法。不同类型的共识算法对应的通信过程不同。可以基于区块链网络中节点之间的通信过程确定当前所运行的共识算法的类型。
本申请实施例中，当区块链网络当前运行第一类型的共识算法时，也即，当区块链网络当前运行崩溃容错共识算法时，崩溃容错共识算法通过以下方式对消息达成共识：响应于消息传递到每个节点，每个节点对消息进行签名处理；响应于区块链网络中正常节点的数量占总节点数量的比例大于或等于响应比例阈值(例如：2/3)，且正常节点响应的共识响应消息中有效共识响应消息占所有的共识响应消息的比例大于有效比例阈值(例如1/2)，确定基于第一类型的共识算法(崩溃容错共识算法)对消息达成共识。达成共识后，将消息以及各节点的签名存储到节点中的区块中。
这里，正常节点是对消息进行响应的节点，有效共识响应消息的签名是有效签名。
示例的，当消息传递到节点时，节点对消息进行签署数字签名，数字签名是利用不对称加密算法的私钥对数字内容的摘要加密形成的密文，数字签名用于证实某数字内容的完整性(integrity)和来源(或不可抵赖，non-repudiation)。当接收到节点反馈的包含有数字签名的共识响应消息时，对共识响应消息携带的数字签名进行解码，得到数字签名对应的数字摘要，将数字摘要与消息对应的原始数字摘要进行比对，当比对结果相同时，说明签名有效，共识响应消息是有效的共识响应消息。
在步骤402A中，响应于区块链网络满足共识环境检测条件，对区块链网络进行共 识环境检测，得到检测结果。
这里，检测结果表征至少部分节点基于共识算法对消息进行共识时是否出错。
示例的，共识环境检测条件包括以下至少一项，以下具体说明。
(1)区块链网络中接入新节点；例如：区块链网络中加入了新接入方，该接入方的多个电子设备(例如终端或服务器)加入了区块链网络，每个电子设备成为一个节点，从而新接入方对应于多个新节点，则满足共识环境检测条件，对区块链网络进行共识环境检测。
(2)区块链网络中至少一个节点的负载超过节点负载阈值。
示例的，节点负载阈值是作为节点的设备能够承担的负载量，当节点的负载超过节点阈值时，节点可能出现宕机等问题，当区块链网络中至少一个节点的负载超过节点负载阈值时，则满足共识环境检测条件，对区块链网络进行共识环境检测。
作为示例，节点的负载值可以采用以下参数至少之一表征：节点中的CPU的使用率；节点中的CPU的输入/输出(I/O，Input/Output)吞吐量。
(3)区块链网络中至少一个接入方对应的负载超过负载阈值。
示例的，区块链网络中存在不同的接入方，例如：应配置为消息的联盟链中，接入方可以分别对应于多个企业、银行以及消息的监督方等，每个接入方向区块链网络中接入多个节点。节点处理数据的能力是有限的，当接入方对应的节点的负载超过该接入方对应的负载阈值，则满足共识环境检测条件，对区块链网络进行共识环境检测。
(4)区块链网络中至少一个网段对应的节点的数量大于网段的节点负载数量阈值。
示例的，网段(Network Segment)是网络中使用同一物理层设备(传输介质、中继器、集线器等)能够直接通讯的部分。区块链网络中的节点可能使用不同的网段，每个网段的通讯负载能力存在对应的阈值，例如：网段的节点负载数量阈值(即网络允许接入的节点的数量的上限)。当至少一个网段接入的的节点的数量大于网段的节点负载数量阈值，则满足共识环境检测条件，对区块链网络进行共识环境检测。
在一些实施例中，还可以基于区块链网络的应用场景设置对应的检测周期，例如：区块链网络应用于消息处理场景，设置检测周期T(例如：1分钟)，每隔一个检测周期则对区块链网络中当前周期内的区块进行检测处理。
在一些实施例中，参考图4B，图4B是本申请实施例提供的区块链网络的共识处理方法的流程示意图，步骤402A可以通过步骤421B至步骤423B实现，以下具体说明。
在步骤421B中，对区块链网络最近的至少一个检测周期内生成的区块进行检测处理，得到多个节点的参数。
这里，参数包括以下至少之一：每个节点的类型、每个节点对应的接入方、每个节点对应的网段。
示例的，参考图5D，是本申请实施例提供的检测周期的示意图；检测周期为T，每个检测周期内依次生成的区块数量为1、2、4、5。在最近的至少一个检测周期内生成的区块中，存储有最近的至少一个检测周期内进行消息处理的节点对于消息的处理结果。可以通过对生成的区块进行检测，得到节点对应的参数。
示例的，根据节点的功能，节点的类型包括：记账节点、背书节点、排序节点、共识节点等。以处理业务相关消息的场景为例，节点对应的接入方的类型包括：消息发起方(例如：企业)、消息处理方(例如：银行)、消息监督方。
作为示例，检测周期可以与区块链网络的区块生成周期(即区块链网络中生成一个新区块所需要的时间)同步，当然，检测周期也可以是区块链网络的区块生成周期的两倍或多倍的数值。
在步骤422B中，确定至少一个检测周期内执行共识处理的每个节点，对每个节点 的共识响应消息签名进行校验处理，得到每个节点的校验结果。
这里，共识响应消息签名正确的节点的校验结果为正确节点，共识响应消息签名错误的节点的校验结果为错误节点。
示例的，基于最近的至少一个检测周期内的产生的区块，确定至少一个检测周期内执行共识处理的每个节点，对每个节点的共识响应消息签名进行校验处理。当接收到节点反馈的包含有数字签名的共识响应消息时，对共识响应消息携带的数字签名进行解码，得到数字签名对应的数字摘要，将数字摘要与消息对应的原始数字摘要进行比对，当比对结果相同时，共识响应消息签名正确，反之错误。
在步骤423B中，将每个节点的校验结果以及至少一项参数作为检测结果。
示例的，基于检测结果可以统计得到：区块链网络中正确节点的数量以及错误节点的数量、共识响应消息的数量、有效的共识响应消息的数量、区块链网络中的接入方、区块链网络中的每个接入方对应的节点数量、区块链网络中不同的网段、区块链网络中每个网段对应的节点数量等数据。
继续参考图4A，在步骤403A中，响应于检测结果满足类型对应的共识算法切换条件，将区块链网络当前所运行的共识算法切换为其他类型的共识算法。
示例的，不同类型的共识算法的共识性能或者容错能力不同，本申请实施例中，针对不同类型的共识算法设置不同的共识算法切换条件，使得共识算法切换能够更加灵活，提升共识算法切换的执行效率，有利于提升区块链网络的容错能力以及稳定性。
在一些实施例中，检测结果包括：一个或多个检测周期内区块链网络中的错误节点的数量；这里，错误节点是针对消息在区块链网络中发送了错误的共识响应消息的节点(例如，拜占庭节点)。
当区块链网络当前运行第二类型的共识算法时，步骤403A可以通过以下方式实现：响应于在一个或多个连续或间隔性的检测周期内在区块链网络中检测到的拜占庭节点的数量小于或者等于共识比例阈值，将区块链网络当前所运行的第二类型的共识算法切换为第一类型的共识算法。
示例的，共识比例阈值可以为0。例如：区块链网络正在运行拜占庭容错算法，响应于连续多个检测周期内均没有检测到拜占庭节点，将拜占庭容错共识算法切换为崩溃容错共识算法。
在一些实施例中，参考图4C，图4C是本申请实施例提供的区块链网络的共识处理方法的流程示意图。当区块链网络当前运行第一类型的共识算法(崩溃容错共识算法)时，步骤403A可以通过步骤431C至步骤433C实现，以下具体说明。
在步骤431C中，基于区块链网络的总节点数量和错误节点的数量，确定错误节点的比例，基于总节点数量以及正常节点的数量，确定正常节点的比例。
示例的，检测结果包括：区块链网络中正常节点的数量以及错误节点的数量；正常节点是未出现运行故障的节点，错误节点是存在运行故障的节点，例如：由于故障运行导致消息错误或者丢失的节点为错误节点，错误节点可以是拜占庭节点。
在步骤432C中，响应于错误节点的比例等于或者大于第二类型的共识算法对应的全局维度容错比例阈值，对错误节点共识的区块进行回退处理。
示例的，全局维度容错比例阈值是正常节点的比例与预设容错比例之间的差值，预设容错比例为2/3。当区块链网络运行崩溃容错共识算法时，主节点可以接收来自从节点的消息。正常节点是检测过程中向主节点发送过消息(正常消息、错误消息)的节点，设正常节点的比例为P，没有检测到向主节点发送消息的节点(可能是正常节点或者故障节点)的占比为(1-P)，假设这部分节点均为拜占庭节点，区块链网络中的错误节点为拜占庭节点，拜占庭节点的占比为Q，则区块链网络中拜占庭节点的总比例为(Q+1-P)。 如果拜占庭节点的比例达到了(P-2/3)，则拜占庭节点的总比例为(P-2/3+1-P)＝1/3。当检测结果中的拜占庭节点的比例大于全局维度容错比例阈值(P-2/3)，说明可以将崩溃容错共识算法切换为拜占庭容错算法。
在进行共识算法切换前，由于区块链网络已经在上述拜占庭错误中达成了共识，可以对本次检测周期内的区块进行回退处理，也即，在每个节点维护的区块链中删除本次检测周期内产生的区块。
在步骤433C中，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
示例的，将区块链网络当前运行的崩溃容错共识算法切换为拜占庭容错算法，提升了区块链网络的容错能力。
在一些实施例中，参考图4D，图4D是本申请实施例提供的区块链网络的共识处理方法的流程示意图。当区块链网络当前运行第一类型的共识算法(崩溃容错共识算法)时，步骤403A可以通过步骤431D至步骤432D实现，以下具体说明。
在步骤431D中，基于总节点数量以及每个接入方对应的错误节点的数量，确定每个接入方对应的错误节点的比例。
示例的，检测结果包括：每个接入方在区块链网络中对应的错误节点的数量，其中，不同的接入方对应于不同的节点，错误节点是存在运行故障的节点。区块链网络中包括多个类型的接入方。
例如：当区块链应用于消息处理时，接入方的类型包括消息发起方(例如：发送业务消息的企业)、消息处理方(例如：处理业务消息的银行)、消息监督方(例如：监督业务消息的机构)。每个接入方对应的节点数量可以是不同的。
假设区块链网络中存在大量的接入方，包括多个不同企业、多个银行以及一个消息监督机构，则将每个接入方对应的错误节点的数量除以相应接入方的总节点数量，得到每个接入方对应的错误节点的比例。
在步骤432D中，响应于区块链网络中的至少一个接入方对应的错误节点的比例大于接入方维度容错比例阈值，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
示例的，不同接入方的接入方维度容错比例阈值可以相同，也可以是差异化的。例如：差异化地根据接入方对应的节点数量设置为不同的比例。至少一个接入方的数量可以根据具体业务场景的容错要求适应设置，例如：区块链网络中的全部接入方或者部分接入方。当至少一个接入方对应的错误节点的比例大于接入方维度容错比例阈值时，对错误节点共识的区块进行回退处理，并将区块链网络当前运行的崩溃容错共识算法切换为拜占庭容错算法。
本申请实施例中，基于接入方维度进行共识算法切换，能够提升区块链网络的容错性能，使得区块链网络更加稳定地运行。
在一些实施例中，参考图4E，图4E是本申请实施例提供的区块链网络的共识处理方法的流程示意图。当区块链网络当前运行第一类型的共识算法(崩溃容错共识算法)时，步骤403A可以通过步骤431E至步骤432E实现，以下具体说明。
在步骤431E中，基于总节点数量以及每个类型的错误节点的数量，确定每个类型的错误节点的比例。
示例的，对应的检测结果包括：区块链网络中每个类型的错误节点的数量，其中，错误节点是存在运行故障的节点。区块链网络中包括多种类型的节点，根据节点的功能，节点的类型包括：记账节点、背书节点、排序节点、共识节点等。将每个类型对应的错误节点的数量除以总节点数量，得到每个类型对应的错误节点的比例。
在步骤432E中，响应于区块链网络中至少一种类型的错误节点的比例大于节点维度容错比例阈值，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
示例的，不同类型节点对应的节点维度容错比例阈值相同，或根据不同接入的容错需求适应设定。至少一个类型的数量可以根据具体业务场景的容错要求适应设置，例如：区块链网络中的全部类型或者部分类型。当至少一个类型对应的错误节点的比例大于类型维度容错比例阈值时，对错误节点共识的区块进行回退处理，并将区块链网络当前运行的崩溃容错共识算法切换为拜占庭容错算法。
本申请实施例中，基于节点类型维度进行共识算法切换，能够提升区块链网络的容错性能，使得区块链网络更加稳定地运行。
在一些实施例中，参考图4F，图4F是本申请实施例提供的区块链网络的共识处理方法的流程示意图。当区块链网络当前运行第一类型的共识算法(崩溃容错共识算法)时，步骤403A可以通过步骤431F至步骤432F实现，以下具体说明。
在步骤431F中，基于总节点数量以及每个网段中的错误节点的数量，确定每个网段的错误节点的比例。
示例的，区块链网络中的多个节点处于多个网段；检测结果包括：区块链网络中每个网段中的错误节点的数量，其中，错误节点是存在运行故障的节点；将每个网段对应的错误节点的数量除以总节点数量，得到每个网段对应的错误节点的比例。
在步骤432F中，响应于区块链网络的至少一个网段的错误节点的比例大于网段维度容错比例阈值，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
示例的，每个网段对应的网段维度容错比例阈值是基于每个网段的容错能力确定的。不同网段的网段维度容错比例阈值可以相同，也可以是差异化的，例如：差异化地根据网段对应的节点数量设置为不同的比例。至少一个网段的数量可以根据具体业务场景的容错要求适应设置，例如：区块链网络中的全部网段或者部分网段。当至少一个网段对应的错误节点的比例大于网段维度容错比例阈值时，对错误节点共识的区块进行回退处理，并将区块链网络当前运行的崩溃容错共识算法切换为拜占庭容错算法。
在一些实施例中，当区块链网络运行第一类型的共识算法时，参考图5A，图5A是本申请实施例提供的区块链网络的共识处理方法的流程示意图。在步骤403A之前，还可以通过执行步骤501A减少切换共识算法前回退的区块数量，以下具体说明。
在步骤501A中，响应于区块链网络中存在错误节点，且错误节点的比例小于第二类型的共识算法对应的容错比例阈值，对区块链网络的区块生成速度进行控制。
示例的，对区块链网络的区块生成速度进行控制，也即，通过减小区块链网络的区块生成周期(例如调整为原区块生成周期的一半或其他小于1的数值)来减慢区块生成速度的增长速度，避免在切换共识算法之前回退过多区块。
这里，错误节点是存在运行故障的节点，容错比例阈值的类型包括：
全局维度容错比例阈值，即区块链网络故障节点的数量与区块链网路的节点总量的比值的上限；
接入方维度容错比例阈值，即某个接入方对应的故障节点的数量与接入方的节点总量的比值的上限；
节点维度容错比例阈值，即某个类型的故障节点(例如故障的背书节点、故障的记账节点、故障的背书节点、故障的排序节点、故障的共识节点)与相应类型的节点总量的比例的上限；
以及网段维度容错比例阈值，即某个网段中的故障节点与网段的节点总量的比例的 上限。
在一些实施例中，参考图5B，图5B是本申请实施例提供的区块链网络的共识处理方法的流程示意图。在步骤403A之后，可以通过执行步骤501B，降低共识算法切换时共识性能变化和容错损耗所引发的负面影响。
在步骤501B中，对区块链网络的区块生成速度进行控制。
示例的，减慢区块生成速度的增长速度，可以避免共识切换后，性能下降可能导致的系统崩溃，以及容错能力降低导致回退过多的区块。步骤501A中所执行的“对区块链网络的区块生成速度进行控制”与步骤501B相同。
在一些实施例中，参考图5C，图5C是本申请实施例提供的区块链网络的共识处理方法的流程示意图。步骤501B可以通过步骤511C以及步骤512C实现，以下具体说明。
在步骤511C中，确定区块链网络在至少一个历史检测周期中的区块生成速度，并确定区块生成速度在多个速度区间中所处的目标速度区间。
示例的，多个速度区间的端点速度依次衔接，多个速度区间之间进行拼接可以组成连续的区间，至少一个历史检测周期可以是最近的多个或者一个历史检测周期。
在一些实施例中，可以通过以下方式确定速度区间：获取区块链网络的最大区块生成速度，基于最大区块生成速度与速度比例阈值确定速度阈值；将零作为第一速度区间，将介于零与速度阈值的区间作为第二速度区间，将大于等于速度阈值且小于最大区块生成速度的区间作为第三速度区间，将等于最大区块生成速度作为第四速度区间。
其中，第一速度区间对应的速度控制方式为控制区块生成速度维持最低区块生成速度，区块生成速度的单位为(区块数量/单位时间)，本申请实施例中区块生成速度的单位为(区块数量/检测周期)，假设每个检测周期为1分钟。最低区块生成速度可以为1分钟1个区块(1个/min)；第二速度区间对应的速度控制方式为控制区块生成速度以指数形式增长，第二速度区间内区块生成速度较低，避免了区块生成速度过快变化造成区块回退过多，在消息处理场景下可以避免产生过多的无效消息，区块生成速度的增长速度可以较其他区间更高，以保证区块生成速度满足区块链网络的需求；第三速度区间对应的速度控制方式为控制区块生成速度匀速增长，也即线性增长，区块链生成速度匀速增长可以提升区块链网络的稳定性；第四速度区间对应的速度控制方式为控制区块生成速度维持最大区块生成速度不变，即此时可以认为区块链网络已经能够平稳运行，保持最大区块生成速度。
示例的，可以将速度比例阈值设置为1/2，则速度阈值是最大区块生成速度的二分之一，速度区间以及每个速度区间对应的速度控制方式可以表示为以下公式(2)。
Figure PCTCN2022132238-appb-000001
其中，a是大于1的正整数，b、k是大于等于1的正整数，a与b可以根据区块链网络的实际需求进行设置，k是检测周期的标号。N k是当前检测周期内的区块生成速度。N k-1是当前检测周期的上一检测周期对应的区块生成速度。第一速度区间为(N k-1＝0)，第二速度区间为(N k-1<M/2)，第三速度区间为(M/2≤N k-1<M)，第四速度区间为(N k-1＝M)。
在一些实施例中，还可以通过以下方式确定速度区间：获取区块链网络的区块的最大区块生成速度；将最大区块生成速度与零之间的区间均匀或不均匀划分为依次衔接的多个速度区间；其中，每个速度区间对应的速度值，与每个速度区间的速度控制方式对应的速度增长速率负相关。
示例的，每个区间内生成速度匀速增长，每个区间对应的区块速度的增长速度形成 降序的等差序列。
示例的，假设速度区间的数量为n+1个，速度区间是均匀的，速度区间以及每个速度区间对应的速度控制方式可以表示为以下公式(3)。
Figure PCTCN2022132238-appb-000002
示例的，c 1、c n是正整数，c 1至c n为生成速度的增长速度，形成逐渐减小的等差序列；d 1、d n是正整数，d 1至d n中包括多个正整数，形成逐渐增加的等差序列。假设：最大区块生成速度M是48个/min，生成多个速度区间，大于等于0且小于10、大于等于10且小于24，大于等于24且小于36，大于等于36且小于48以及等于48，除等于48以外的每个区间内生成速度匀速增长，每个区间对应的增长速度分别为2、4、6、8，每个区间对应的增长速度形成降序的等差序列。
在步骤512C中，基于目标速度区间对应的速度控制方式，对区块链网络在当前检测周期中的区块生成速度进行控制。
这里，不同的速度区间对应的速度控制方式不同。
示例的，以下举例进行说明，假设采用上文中公式(2)对应的区间进行区块生成速度控制。假设：检测周期为1分钟，最大区块生成速度M为每分钟1024个区块(1024个/min)。初始的区块生成速度N 0＝0，第一检测周期内的区块生成速度为N 1＝1。
各检测周期内的区块生成速度依次为1、4个/min、8个/min、16个/min……512个/min(第二速度区间内以指数形式增长，第二速度区间为大于0且小于512个/min)、513、514……1024(第三速度区间为大于等于512个/min且小于1024个/min，当区块生成速度达到1024个/min时，也即第四速度区间，区块生成速度维持1024个/min不变)。
本申请实施例所提供的区块链网络的共识处理方法，使得区块链网络在网络环境中无拜占庭节点时，切换到崩溃容错类共识，从而满足性能需求高的应用场景；当检测到区块链网络中存在一定数量的拜占庭节点时，将共识算法切换为拜占庭容错类共识，提供更好的容错能力。在共识算法切换后对区块生成速度进行控制，能够降低共识算法切换时共识性能变化和容错损耗所引发的负面影响。使用本申请实施例的共识方案，能够根据业务场景的变化自适应地切换共识算法，既能提供更好的容错能力也能满足性能要求高的应用场景需求。
下面，以本申请实施例提供的区块链网络的共识处理方法可以应用在联盟链中的消息处理场景中为例说明。
在处理业务相关消息的场景中，无论是资产的转移、买卖等(例如，网络游戏中的游戏资产)，都需要防止恶意节点作恶。拜占庭容错类的共识算法能够用于对恶意节点进行容错，保证消息结果的正确性。另一方面，消息处理场景也需要高效的共识算法来实现高吞吐量，崩溃容错类的共识算法具有更好的性能。本申请实施例提供的区块链网络的共识处理方法开源应用在联盟链的消息处理场景中，使共识算法灵活切换，保证系统(也即区块链网络，下文中的系统均是指区块链网络)的容错能力和性能。
参考图6，图6是本申请实施例提供的崩溃容错类的共识算法的共识过程示意图。本申请实施例中以崩溃容错类中的递归容错算法(RAFT，Recursive Algorithm for Fault Tolerance)的共识过程为例进行说明，共识过程可以抽象为准备阶段和提交阶段，主节点C1收到客户端K1的消息后，进入准备阶段，由主节点同步日志记录给从节点(从节点C2、从节点C3以及从节点C4)，从节点收到消息后，发送响应给主节点C1，主节点C1收到半数以上的响应后，进入提交阶段，主节点C1发送消息给从节点，进行 数据提交，并返回结果给客户端K1。Raft的共识过程包括两个阶段，且每个阶段只包含主节点和从节点之间的通信过程，从节点间无需进行交互，整体的通信复杂度为O(n)，n为节点的数量。因此，以Raft为代表的崩溃容错类共识算法通常具有较高的吞吐量，因而整体系统能够达到较高的性能。崩溃容错类共识能够容忍的最大崩溃错误节点数量为(n-1)/2，n是大于等于1的正整数。
参考图7，图7是本申请实施例提供的拜占庭容错类的共识算法的共识过程示意图。拜占庭容错类共识算法通常需要三轮通信过程来达成共识，本申请实施例中以拜占庭容错类中的实用拜占庭容错(PBFT，Practical Byzantine Fault Tolerance)共识算法为例进行说明，主节点B1收到客户端K2请求后，进入预准备阶段，主节点B1向所有从节点(从节点B2、从节点B3、从节点B4)发送消息，从节点收到消息并进行检查(例如，校验签名等)，检查无误后，进入准备阶段；各节点将消息封装(例如签名等操作)后，进一步广播给其余节点，当节点收到的正确消息大于等于2f+1(包括节点本身)，其中，f是大于等于1的正整数，进入提交阶段；各节点将消息进行封装并广播给其余节点，当收到的正确提交消息大于等于2f+1后(包括节点本身)，共识达成，进行数据提交，同时将响应请求消息发送给客户端。如图2所示，在存在1个拜占庭节点时，系统仍能达成共识。拜占庭容错类共识能够容忍的拜占庭节点数量为f＝(n-1)/3，从节点数量的1/3，其中n为网络中节点总数量(1个主节点与n-1个从节点)
本申请实施例提供了一种区块链的共识处理方法，能够根据运行环境的变化自适应地切换不同共识算法，涉及到拜占庭容错类共识算法和崩溃容错类共识算法的切换。
本申请实施例中，针对崩溃容错类共识算法采用以下方式达成共识：响应于消息传递到每个节点，每个节点对消息进行签名处理；响应于区块链网络中正常节点的数量占总节点数量的比例大于或等于响应比例阈值(例如：2/3)，且正常节点响应的共识响应消息中有效共识响应消息占所有的共识响应消息的比例大于有效比例阈值(例如1/2)，确定基于第一类型的共识算法对消息达成共识。
当前的共识算法为拜占庭容错算法时，参考图8A，图8A是本申请实施例提供的区块链的共识处理方法的流程示意图，以下具体说明。
在步骤801A中，共识环境检测。
示例的，共识环境检测中检测的指标为当前系统运行环境中拜占庭节点的数量。检测的方法为校验区块中各节点的共识消息签名：节点校验成功，则表示节点未出现拜占庭错误；节点校验失败，则表示出现拜占庭错误或者其他错误。
参考图5D，图5D是本申请实施例提供的检测周期的示意图；共识环境检测每隔单位时间T进行一次，如图5D所示，时间T可以根据业务场景的不同进行设置。例如，需要频繁进行检测的场景可以设置较小的T值，例如：处理业务相关消息的场景中，将T设置为预设秒数(例如5秒)频繁地进行检查，或者将T设置为预设分钟(例如1分钟)。每次检测的范围为当前单位时间T内(也即上文中的检测周期)产生的区块，单位时间T(例如：1分钟)内产生的区块数量由切换过渡策略(也即，本申请实施例中对区块生成速度进行控制的处理)决定。
在步骤802A中，判断是否满足共识切换条件。在步骤802A的判断结果为是时，执行步骤803A，若否则继续执行步骤801A。
示例的，拜占庭容错算法下，共识切换条件为：连续多次共识环境检测均未出现拜占庭错误(即拜占庭节点数量为0)。满足共识切换条件，表明此时运行环境中节点是可信的，此时将拜占庭容错算法切换为崩溃容错算法，能够提升系统性能。具体的检测次数可以根据业务场景自定义，如果需要更加可靠的容错，可设置更大的次数值。
在步骤803A中，切换共识算法。
示例的，在当前共识算法为拜占庭容错算法时，切换共识算法也即将当前共识算法切换为崩溃容错算法。
在步骤804A中，应用切换过渡策略。
示例的，为避免共识切换后，性能下降可能导致的系统崩溃，以及容错能力降低导致回退过多的区块。因而在切换共识算法后，运行切换过渡策略，对切换后的区块生成速度(即共识速度)进行控制。切换过渡策略用于控制共识算法切换之后区块的生成速度，防止系统崩溃或区块回退过多。
示例的，参考图8C，图8C是本申请实施例提供的区块链的共识处理方法的流程示意图。步骤804A可以通过步骤801C至步骤806C实现。
在步骤801C中，确定共识算法切换完成。
示例的，当区块链网络中各节点均采用相同的共识算法时，确定共识算法切换完成。
在步骤802C中，以指数规律增加单个共识轮次区块生成数量。
示例的，本申请实施例以共识算法切换完成后，区块生成速度为零为例进行说明。切换过渡策略通过限制单位时间T内生成的区块数量来控制区块的生成速度，单位时间T是上文中执行共识检测的检测周期。区块生成速度可以表征为，每个单位时间内的区块生成数量。假设每个单位时间T为一个共识检测轮次(每个共识检测轮次对应于一次共识检测)，用N表示每个共识检测轮次产生的区块数量，第k个共识检测轮次产生的区块数量为N k，k大于等于1。每次应用切换过渡策略，均重新开始累计共识检测轮次，即每次应用过渡策略时共识检测轮次的初始值均为k＝1，系统在当前共识算法下，单个共识检测轮次生成的最大区块数量为M，N k的计算方式如下公式(1)所示,N k的初始值N 0＝0，N 1＝1，N k-1是上一共识检测轮次产生的区块数量。
Figure PCTCN2022132238-appb-000003
以上N k的计算分别对应区块慢生成(通过步骤802C实现，对应于区间N k-1<M/2)、损耗避免(通过步骤804C实现，对应于区间M/2≤N k-1<M)、平稳运行(通过步骤806C实现，对应于区间N k-1＝M)三个阶段，区块慢生成对应于步骤802C，当单个共识检测轮次(时间T)中生成的区块数量小于M/2(区块的生成速度较小，即时间T内产生的区块数量较少)时，控制每个共识检测轮次中生成的区块呈指数增长(也即，区块生成速度以指数形式增长)。
在步骤803C中，判断单轮次区块生成数量是否小于M/2。当判断结果为是时，执行步骤802C，若否则执行步骤804C。
示例的，当单轮次区块生成数量小于M/2时，此时区块生成速度的增长速率高，但单个共识检测轮次中区块数量少，若此时发生共识切换，需要回退的区块数量也相对较小，在消息处理场景中可以避免产生过多的无效消息。同时在切换之后保持较低的区块生成速率，也能防止节点无法处理大量请求而造成的系统崩溃。
在步骤804C中，以线性规律增加单个共识轮次区块生成数量。
示例的，当单个共识检测轮次中生成的区块大于等于M/2且小于
Figure PCTCN2022132238-appb-000004
时，控制区块的增长速率减慢，具体为，每个共识检测轮次中区块的生成数量呈线性增长，也即，控制区块的生成速度的增长速度保持不变(N k＝N k-1+1)。
在步骤805C中，判断单轮次区块生成数量是否小于M。当判断结果为是时，执行步骤804C，若否则执行步骤806C。
在步骤806C中，单轮次区块生成数量维持在M，系统平稳运行。
示例的，当区块的生成速率达最大值(M/T)后，也即单个共识检测轮次中产生的区块数量为M，即此时可以认为系统已经能够平稳运行，无需再对区块的生成速度进行控制。(N k＝M)。
示例的，假设M＝1024，各轮的共识生成的区块数量依次为，1、4、8、16……512(1到512以指数形式增长)、513、514……1024(513至1024以匀速形式增长，当达到1024时，维持1024不变)。
本申请实施例，在共识算法切换之后，采用区块慢生成能够快速提升系统整体的吞吐量，而由于此时单个轮次中的区块数量还相对较少，因而即使此时需要进行区块回退，也不会产生过多的无效消息。当系统的吞吐率(即单个共识检测轮次的区块生成数量)到达一定阈值时，开始进入损耗避免阶段，此时系统整体的性能已基本能够支撑系统的请求量，因此降低区块生成速率的增长速度，避免区块生成速度以指数形式递增而生成过多的区块，进而避免对区块进行回退处理时产生大量无效消息。当系统性能达到最大值时，此时已经无需再对区块生成速率进行限制，系统进入平稳运行阶段。
当前的共识算法为崩溃容错算法时，参考图8B，图8B是本申请实施例提供的区块链的共识处理方法的流程示意图，以下具体说明。
在步骤801B中，共识环境检测。
示例的，步骤801B的执行可以参考步骤801A。
在步骤802B中，判断是否满足共识切换条件。当判断结果为是时，执行步骤803C，当判断结果为否时，执行步骤804C。
示例的，崩溃容错算法对应的共识切换条件为：检测到某次共识过程拜占庭节点的比例大于
Figure PCTCN2022132238-appb-000005
则进行共识算法切换。P为共识过程中主节点收到来自不同节点消息的数量与总节点数之间的比例。假设，其余节点未收到消息的(1-P)节点均为拜占庭节点，若某次共识过程中检测到的拜占庭节点大于
Figure PCTCN2022132238-appb-000006
则网络中拜占庭节点总比例将大于
Figure PCTCN2022132238-appb-000007
即大于
Figure PCTCN2022132238-appb-000008
表明当前可能出现了拜占庭容错类共识无法容忍的拜占庭节点数量，为实现系统整体的拜占庭容错能力，因而当拜占庭节点的比例大于
Figure PCTCN2022132238-appb-000009
时，将共识算法切换为拜占庭容错算法来防止拜占庭节点继续作恶可能导致的系统异常。
在步骤803B中，切换共识算法。
示例的，当前共识算法为崩溃容错算法时，由于系统(区块链网络)已经在上述拜占庭错误中达成了共识，先回退本次检测周期内的区块，再将共识算法切换为拜占庭容错算法。
在步骤804B中，当前轮次中是否存在拜占庭错误。当判断结果为是时，执行步骤805B，若否则执行步骤801B。
示例的，若检测到存在拜占庭错误的节点，但未达到共识切换的阈值时，此时执行切换过渡策略，减慢区块的生成速度，避免出现切换共识算法时回退过多的区块。
在步骤805B中，应用切换过渡策略。
示例的，步骤805B也可以通过步骤801C至步骤806C实现，此处不再赘述。
下面再结合人工智能领域的联邦学习场景说明本申请实施例提供的共识处理方法。
用户A、用户B、用户C正在进行针对物品推荐模型的联邦学习任务，用户A拥有针对物品推荐模型的第一部分训练数据，用户B拥有针对物品推荐模型的第二部分训练数据，用户C拥有针对物品推荐模型的第三部分训练数据，其中，第一部分训练数据、第二训练部分数据以及第三部分训练数据构成配置为训练物品推荐模型的完整训练数 据。
因此，用户A通过终端设备(运行区块链网络的客户端)，向区块链网络发起基于第一部分训练数据训练物品推荐模型的请求，用户B通过所使用的终端设备(运行区块链网络的客户端)，向区块链网络发起基于第二部分训练数据训练物品推荐模型的请求，用户C通过终端设备(运行区块链网络的客户端)，向区块链网络发起基于第一部分训练数据训练物品推荐模型的请求。
区块链网络中的节点充当了训练设备的角色，通过上述的训练数据，结合联邦学习算法训练物品推荐模型，在训练过程中，携带每个节点的物品推荐模型的参数的消息，都需要通过共识算法取得其他节点的一致认可，之后，才会配置为更新物品推荐模型，这保证了模型更新的可靠性。
区块链网络中的节点默认采用第一类型的共识算法以实现高于第二共识算法的共识性能。在训练过程中，每个节点还会进行共识环境检测，如果检测结果表征至少部分节点基于共识算法对消息进行共识时出错，说明区块链网络中引入了不稳定因素(例如网络通信质量抖动、加入了作恶节点等)，则会切换到第二共识算法，由于第二共识算法的容错性能高于第一共识算法，因此，能够保证对物品推荐模型参数的可靠共识，避免向物品推荐模型引入错误的参数，保证了物品推荐模型的准确和可靠更新。
本申请实施例所提供的区块链网络的共识处理方法，使得区块链网络在网络环境中无拜占庭节点时，切换到崩溃容错类共识，从而满足性能需求高的应用场景；当检测到系统中存在一定数量的拜占庭节点时，将共识算法切换为拜占庭容错类共识，提供更好的容错能力。本申请所提供的切换过渡策略能够降低共识算法切换时共识性能变化和容错损耗所引发的负面影响。使用本申请实施例的共识方案，能够根据业务场景的变化自适应地切换共识算法，既能提供更好的容错能力也能满足性能要求高的应用场景需求。
下面继续说明本申请实施例提供的区块链网络的共识处理装置655的实施为软件模块的示例性结构，在一些实施例中，如图3所示，区块链网络包括多个节点，多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识处理；存储在存储器650的区块链网络的共识处理装置655中的软件模块可以包括：数据采集区块链模块6551，配置为获取区块链网络当前所运行的共识算法的类型；共识检测区块链模块6552，配置为响应于区块链网络满足共识环境检测条件，对区块链网络进行共识环境检测，得到检测结果，其中，检测结果表征至少部分节点基于共识算法对消息进行共识时是否出错；共识切换区块链模块6553，配置为响应于检测结果满足类型对应的共识算法切换条件，将区块链网络当前所运行的共识算法切换为其他类型的共识算法；其中，共识算法的类型包括第一类型与第二类型，第一类型的共识算法的共识性能高于第二类型的共识算法的共识性能，第二类型的共识算法的容错性能大于第一类型的共识算法的容错性能。
在一些实施例中，当区块链网络当前运行第二类型的共识算法时，检测结果包括：一个或多个检测周期内区块链网络中的错误节点的数量；其中，错误节点是针对消息发送了错误的共识响应消息的节点；共识切换区块链模块6553，配置为响应于在一个或多个检测周期内在区块链网络中检测到的错误节点的数量小于或者等于共识比例阈值，将区块链网络当前所运行的第二类型的共识算法切换为第一类型的共识算法。
在一些实施例中，当区块链网络运行第一类型的共识算法时，检测结果包括：区块链网络中正常节点的数量以及错误节点的数量；其中，正常节点是未出现运行故障的节点，错误节点是存在运行故障的节点；共识切换区块链模块6553，配置为基于区块链网络的总节点数量和错误节点的数量，确定错误节点的比例，基于总节点数量以及正常节点的数量，确定正常节点的比例；响应于错误节点的比例等于或者大于第二类型的共识算法对应的全局维度容错比例阈值，对错误节点共识的区块进行回退处理，其中，全局 维度容错比例阈值是正常节点的比例与预设容错比例之间的差值；将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
在一些实施例中，当区块链网络运行第一类型的共识算法时，检测结果包括：每个接入方在区块链网络中对应的错误节点的数量，其中，不同的接入方对应于不同的节点，错误节点是存在运行故障的节点；共识切换区块链模块6553，配置为基于总节点数量以及每个接入方对应的错误节点的数量，确定每个接入方对应的错误节点的比例；响应于区块链网络中的至少一个接入方对应的错误节点的比例大于接入方维度容错比例阈值，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
在一些实施例中，多个节点分别属于多个类型；当区块链网络运行第一类型的共识算法时，检测结果包括：区块链网络中每个类型的错误节点的数量，其中，错误节点是存在运行故障的节点；共识切换区块链模块6553，配置为基于总节点数量以及每个类型的错误节点的数量，确定每个类型的错误节点的比例；响应于区块链网络中至少一种类型的错误节点的比例大于节点维度容错比例阈值，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
在一些实施例中，区块链网络中的多个节点处于多个网段；检测结果包括：区块链网络中每个网段中的错误节点的数量，其中，错误节点是存在运行故障的节点；当区块链网络运行第一类型的共识算法时，共识切换区块链模块6553，配置为基于总节点数量以及每个网段中的错误节点的数量，确定每个网段的错误节点的比例；响应于区块链网络的至少一个网段的错误节点的比例大于网段维度容错比例阈值，将区块链网络当前所运行的第一类型的共识算法切换为第二类型的共识算法。
在一些实施例中，当区块链网络运行第一类型的共识算法时，共识切换区块链模块6553，配置为响应于区块链网络中存在错误节点，且错误节点的比例小于第二类型的共识算法对应的容错比例阈值，对区块链网络的区块生成速度进行控制；其中，错误节点是存在运行故障的节点，容错比例阈值的类型包括：全局维度容错比例阈值、接入方维度容错比例阈值、节点维度容错比例阈值以及网段维度容错比例阈值。
在一些实施例中，共识切换区块链模块6553，配置为对区块链网络的区块生成速度进行控制。
在一些实施例中，共识切换区块链模块6553，配置为确定区块链网络在至少一个历史检测周期中的区块生成速度，并确定区块生成速度在多个速度区间中所处的目标速度区间，其中，多个速度区间的端点速度依次衔接；基于目标速度区间对应的速度控制方式，对区块链网络在当前检测周期中的区块生成速度进行控制，其中，不同的速度区间对应的速度控制方式不同。
在一些实施例中，共识切换区块链模块6553，配置为获取区块链网络的最大区块生成速度，基于最大区块生成速度与速度比例阈值确定速度阈值；将零作为第一速度区间，将介于零与速度阈值的区间作为第二速度区间，将大于等于速度阈值且小于最大区块生成速度的区间作为第三速度区间，将等于最大区块生成速度作为第四速度区间；其中，第一速度区间对应的速度控制方式为控制区块生成速度维持最低区块生成速度，第二速度区间对应的速度控制方式为控制区块生成速度以指数形式增长，第三速度区间对应的速度控制方式为控制区块生成速度匀速增长，第四速度区间对应的速度控制方式为控制区块生成速度维持最大区块生成速度不变。
在一些实施例中，共识切换区块链模块6553，配置为获取区块链网络的区块的最大区块生成速度；将最大区块生成速度与零之间的区间划分为依次衔接的多个速度区间；其中，每个速度区间对应的速度值与每个速度区间的速度控制方式对应的速度增长速率负相关。
在一些实施例中，共识切换区块链模块6552，配置为对区块链网络最近的至少一个检测周期内生成的区块进行检测处理，得到多个节点的参数，其中，参数包括以下至少之一：每个节点的类型、每个节点对应的接入方、每个节点对应的网段；确定至少一个检测周期内执行共识处理的每个节点，对每个节点的共识响应消息签名进行校验处理，得到每个节点的校验结果，其中，共识响应消息签名正确的节点的校验结果为正确节点，共识响应消息签名错误的节点的校验结果为错误节点；将每个节点的校验结果以及至少一项参数作为检测结果。
在一些实施例中，共识环境检测条件包括以下至少之一：区块链网络中接入新节点；区块链网络中至少一个节点的负载超过节点负载阈值；区块链网络中至少一个接入方对应的负载超过负载阈值；区块链网络中至少一个网段对应的节点的数量大于网段的节点负载数量阈值。
在一些实施例中，共识检测区块链模块6552，配置为响应于消息传递到每个节点，对消息进行签名处理；响应于区块链网络中正常节点的数量占总节点数量的比例大于或等于响应比例阈值，且正常节点的共识响应消息中的有效共识响应消息的比例大于有效比例阈值，确定基于第一类型的共识算法对消息达成共识，其中，正常节点是对消息进行响应的节点，有效共识响应消息的签名是有效签名。
本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的区块链网络的共识处理方法。
本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的区块链网络的共识处理方法，例如，如图4A至图4F、图5A至图5C任一附图示出的区块链网络的共识处理方法。
在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
综上所述，通过本申请实施例，在满足共识环境检测条件时，基于共识检测结果与共识算法对应的切换条件对区块链网络进行共识算法切换，使得区块链网络的共识算法切换更灵活，更符合区块链网络的容错需求，提升区块链网络的容错能力以及运行的稳定性。在共识算法切换后，通过对区块生成速度进行控制，能够降低共识算法切换时共识性能变化和容错损耗所引发的负面影响。使用本申请实施例的共识方案，能够根据业务场景的变化自适应地切换共识算法，既能提供更好的容错能力也能满足性能要求高的应用场景需求。
以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (21)

  1. 一种区块链网络的共识处理方法，由电子设备执行，所述电子设备运行所述区块链网络包括的多个节点，所述多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识处理；
    所述方法包括：
    获取所述区块链网络当前所运行的所述共识算法的类型；
    响应于所述区块链网络满足共识环境检测条件，对所述区块链网络进行共识环境检测，得到检测结果，其中，所述检测结果表征所述至少部分节点基于所述共识算法对所述消息进行共识时是否出错；
    响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法；
    其中，所述共识算法的类型包括第一类型与第二类型，所述第一类型的共识算法的共识性能高于所述第二类型的共识算法的共识性能，所述第二类型的共识算法的容错性能大于所述第一类型的共识算法的容错性能。
  2. 如权利要求1所述的方法，其中，
    当所述区块链网络当前运行所述第二类型的共识算法时，所述检测结果包括：一个或多个检测周期内所述区块链网络中的错误节点的数量；其中，所述错误节点是针对所述消息发送了错误的共识响应消息的节点；
    所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法，包括：
    响应于在一个或多个检测周期内在所述区块链网络中检测到的所述错误节点的数量小于或者等于共识比例阈值，将所述区块链网络当前所运行的所述第二类型的共识算法切换为所述第一类型的共识算法。
  3. 如权利要求1所述的方法，其中，
    当所述区块链网络当前运行所述第一类型的共识算法时，所述检测结果包括：所述区块链网络中正常节点的数量以及错误节点的数量；其中，所述正常节点是未出现运行故障的节点，所述错误节点是存在运行故障的节点；
    所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法，包括：
    基于所述区块链网络的总节点数量和所述错误节点的数量，确定所述错误节点的比例，基于所述总节点数量以及所述正常节点的数量，确定所述正常节点的比例；
    响应于所述错误节点的比例等于或者大于所述第二类型的共识算法对应的全局维度容错比例阈值，对所述错误节点共识的区块进行回退处理，其中，所述全局维度容错比例阈值是所述正常节点的比例与预设容错比例之间的差值；
    将所述区块链网络当前所运行的所述第一类型的共识算法切换为所述第二类型的共识算法。
  4. 如权利要求1所述的方法，其中，当所述区块链网络当前运行所述第一类型的共识算法时，所述检测结果包括：每个接入方在所述区块链网络中对应的错误节点的数量，其中，不同的所述接入方对应于不同的所述节点，所述错误节点是存在运行故障的节点；
    所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法，包括：
    基于所述总节点数量以及所述每个接入方对应的错误节点的数量，确定所述每个接入方对应的错误节点的比例；
    响应于所述区块链网络中的至少一个所述接入方对应的错误节点的比例大于接入方维度容错比例阈值，将所述区块链网络当前所运行的所述第一类型的共识算法切换为所述第二类型的共识算法。
  5. 如权利要求1所述的方法，其中，
    所述多个节点分别属于多个类型；当所述区块链网络当前运行所述第一类型的共识算法时，所述检测结果包括：所述区块链网络中每个所述类型的错误节点的数量，其中，所述错误节点是存在运行故障的节点；
    所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法，包括：
    基于所述总节点数量以及每个所述类型的错误节点的数量，确定每个所述类型的错误节点的比例；
    响应于所述区块链网络中至少一种类型的错误节点的比例大于节点维度容错比例阈值，将所述区块链网络当前所运行的所述第一类型的共识算法切换为所述第二类型的共识算法。
  6. 如权利要求1所述的方法，其中，
    所述区块链网络中的所述多个节点处于多个网段；当所述区块链网络当前运行所述第一类型的共识算法时，所述检测结果包括：所述区块链网络中每个所述网段中的错误节点的数量，其中，所述错误节点是存在运行故障的节点；
    所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法，包括：
    基于所述总节点数量以及每个所述网段中的错误节点的数量，确定每个所述网段的错误节点的比例；
    响应于所述区块链网络的至少一个网段的错误节点的比例大于网段维度容错比例阈值，将所述区块链网络当前所运行的所述第一类型的共识算法切换为所述第二类型的共识算法。
  7. 如权利要求1所述的方法，其中，当所述区块链网络运行所述第一类型的共识算法时，所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法之前，所述方法还包括：
    响应于所述区块链网络中存在错误节点，且所述错误节点的比例小于所述第二类型的共识算法对应的容错比例阈值，对所述区块链网络的区块生成速度进行控制；
    其中，所述错误节点是存在运行故障的节点，所述容错比例阈值的类型包括：全局维度容错比例阈值、接入方维度容错比例阈值、节点维度容错比例阈值以及网段维度容错比例阈值。
  8. 如权利要求1所述的方法，其中，所述响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法之后，所述方法还包括：
    对所述区块链网络的区块生成速度进行控制。
  9. 如权利要求7或8所述的方法，其中，所述对所述区块链网络的区块生成速度进行控制，包括：
    确定所述区块链网络在至少一个历史检测周期中的区块生成速度，并确定所述区块生成速度在多个速度区间中所处的目标速度区间，其中，所述多个速度区间的端点速度依次衔接；
    基于所述目标速度区间对应的速度控制方式，对所述区块链网络在当前检测周期中的区块生成速度进行控制，其中，不同的所述速度区间对应的速度控制方式不同。
  10. 如权利要求9所述的方法，其中，所述确定所述区块链网络在至少一个历史检测周期中的区块生成速度之前，所述方法还包括：
    获取所述区块链网络的最大区块生成速度，基于所述最大区块生成速度与速度比例阈值确定速度阈值；
    将零作为第一速度区间，将介于零与所述速度阈值的区间作为第二速度区间，将大于等于所述速度阈值且小于所述最大区块生成速度的区间作为第三速度区间，将等于所述最大区块生成速度作为第四速度区间；
    其中，所述第一速度区间对应的速度控制方式为控制所述区块生成速度维持最低区块生成速度，所述第二速度区间对应的速度控制方式为控制所述区块生成速度以指数形式增长，所述第三速度区间对应的速度控制方式为控制所述区块生成速度匀速增长，所述第四速度区间对应的速度控制方式为控制所述区块生成速度维持所述最大区块生成速度不变。
  11. 如权利要求9所述的方法，其中，所述确定所述区块链网络在至少一个历史检测周期中的区块生成速度之前，所述方法还包括：
    获取所述区块链网络的区块的最大区块生成速度；
    将所述最大区块生成速度与零之间的区间划分为依次衔接的多个速度区间；
    其中，每个所述速度区间对应的速度值与每个所述速度区间的速度控制方式对应的速度增长速率负相关。
  12. 如权利要求1所述的方法，其中，所述对所述区块链网络进行共识环境检测，得到检测结果，包括：
    对所述区块链网络最近的至少一个检测周期内生成的区块进行检测处理，得到所述多个节点的参数，其中，所述参数包括以下至少之一：每个所述节点的类型、每个所述节点对应的接入方、每个所述节点对应的网段；
    确定所述至少一个检测周期内执行共识处理的每个所述节点，对每个所述节点的共识响应消息签名进行校验处理，得到每个所述节点的校验结果，其中，共识响应消息签名正确的所述节点的所述校验结果为正确节点，共识响应消息签名错误的所述节点的所述校验结果为错误节点；
    将每个所述节点的校验结果以及所述至少一项参数作为检测结果。
  13. 如权利要求1所述的方法，其中，所述共识环境检测条件包括以下至少之一：
    所述区块链网络中接入新节点；
    所述区块链网络中至少一个所述节点的负载超过节点负载阈值；
    所述区块链网络中至少一个接入方对应的负载超过负载阈值；
    所述区块链网络中至少一个网段对应的节点的数量大于所述网段的节点负载数量阈值。
  14. 如权利要求1所述的方法，其中，当所述区块链网络当前运行所述第一类型的共识算法时，所述方法还包括：
    响应于所述消息传递到每个所述节点，对所述消息进行签名处理；
    响应于所述区块链网络中正常节点的数量占总节点数量的比例大于或等于响应比例阈值，且所述正常节点的共识响应消息中的有效共识响应消息的比例大于有效比例阈值，确定基于所述第一类型的共识算法对所述消息达成共识，其中，所述正常节点是对所述消息进行响应的节点，所述有效共识响应消息的签名是有效签名。
  15. 一种区块链网络的共识处理方法，
    所述区块链网络包括多个节点，所述多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识；
    所述方法包括：
    确定所述区块链网络在至少一个历史检测周期中的区块生成速度，并确定所述区块生成速度在多个速度区间中所处的目标速度区间，其中，所述多个速度区间的端点速度依次衔接；
    基于所述目标速度区间对应的速度控制方式，对所述区块链网络在当前检测周期中的区块生成速度进行控制，其中，不同的所述速度区间对应的速度控制方式不同。
  16. 如权利要求15所述的方法，其中，所述确定所述区块链网络在至少一个历史检测周期中的区块生成速度之前，所述方法还包括：
    获取所述区块链网络的最大区块生成速度，基于所述最大区块生成速度与速度比例阈值确定速度阈值；
    将零作为第一速度区间，将介于零与所述速度阈值的区间作为第二速度区间，将大于等于所述速度阈值且小于所述最大区块生成速度的区间作为第三速度区间，将等于所述最大区块生成速度作为第四速度区间；
    其中，所述第一速度区间对应的速度控制方式为控制所述区块生成速度维持最低区块生成速度，所述第二速度区间对应的速度控制方式为控制所述区块生成速度以指数形式增长，所述第三速度区间对应的速度控制方式为控制所述区块生成速度匀速增长，所述第四速度区间对应的速度控制方式为控制所述区块生成速度维持所述最大区块生成速度不变。
  17. 如权利要求15所述的方法，其中，所述确定所述区块链网络在至少一个历史检测周期中的区块生成速度之前，所述方法还包括：
    获取所述区块链网络的区块的最大区块生成速度；
    将所述最大区块生成速度与零之间的区间划分为依次衔接的多个速度区间；
    其中，每个所述速度区间对应的速度值与每个所述速度区间的速度控制方式对应的速度增长速率负相关。
  18. 一种区块链的共识处理装置，所述区块链网络包括多个节点，所述多个节点中至少部分节点配置为基于共识算法对客户端发送的消息进行共识处理，所述区块链的共识处理装置包括：
    数据采集区块链模块，配置为获取所述区块链网络当前所运行的所述共识算法的类型；
    共识检测区块链模块，配置为响应于所述区块链网络满足共识环境检测条件，对所述区块链网络进行共识环境检测，得到检测结果，其中，所述检测结果表征所述至少部分节点基于所述共识算法对所述消息进行共识时是否出错；
    共识切换区块链模块，配置为响应于所述检测结果满足所述类型对应的共识算法切换条件，将所述区块链网络当前所运行的所述共识算法切换为其他类型的共识算法；
    其中，所述共识算法的类型包括第一类型与第二类型，所述第一类型的共识算法的共识性能高于所述第二类型的共识算法的共识性能，所述第二类型的共识算法的容错性能大于所述第一类型的共识算法的容错性能。
  19. 一种运行区块链网络的节点的电子设备，所述电子设备包括：
    存储器，用于存储可执行指令；
    处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至17任一项所述的区块链网络的共识方法。
  20. 一种计算机可读存储介质，存储有可执行指令，所述可执行指令被处理器执行时实现权利要求1至17任一项所述的区块链网络的共识方法。
  21. 一种计算机程序产品，包括计算机程序或指令，所述计算机程序或指令被处理器执行时实现权利要求1至17任一项所述的区块链网络的共识方法。
PCT/CN2022/132238 2022-03-24 2022-11-16 区块链网络的共识处理方法、装置、设备及存储介质、程序产品 WO2023179056A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/239,843 US20230409450A1 (en) 2022-03-24 2023-08-30 Consensus processing method and apparatus for blockchain network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210302668.6 2022-03-24
CN202210302668.6A CN116846888A (zh) 2022-03-24 2022-03-24 区块链网络的共识处理方法、装置、设备及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/239,843 Continuation US20230409450A1 (en) 2022-03-24 2023-08-30 Consensus processing method and apparatus for blockchain network

Publications (1)

Publication Number Publication Date
WO2023179056A1 true WO2023179056A1 (zh) 2023-09-28

Family

ID=88099742

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/132238 WO2023179056A1 (zh) 2022-03-24 2022-11-16 区块链网络的共识处理方法、装置、设备及存储介质、程序产品

Country Status (3)

Country Link
US (1) US20230409450A1 (zh)
CN (1) CN116846888A (zh)
WO (1) WO2023179056A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117478299A (zh) * 2023-12-27 2024-01-30 湖南天河国云科技有限公司 区块链共识算法切换方法、装置和计算机设备

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106878071A (zh) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 一种基于Raft算法的区块链共识机制
CN107577694A (zh) * 2017-07-14 2018-01-12 阿里巴巴集团控股有限公司 一种基于区块链的数据处理方法及设备
CN108235799A (zh) * 2017-12-27 2018-06-29 深圳达闼科技控股有限公司 区块生成方法、装置、存储介质、区块链网络
CN110598471A (zh) * 2019-09-17 2019-12-20 深圳市网心科技有限公司 基于区块链的时间戳生成方法、装置、系统及存储介质
US20200112443A1 (en) * 2018-10-04 2020-04-09 EMC IP Holding Company LLC Policy-driven dynamic consensus protocol selection
CN111464356A (zh) * 2020-04-01 2020-07-28 腾讯科技（深圳）有限公司 一种区块共识周期切换方法、装置及计算机设备
CN112564960A (zh) * 2020-12-01 2021-03-26 浙商银行股份有限公司 基于区块链节点中心度弹性调整共识的方法及装置
CN113764060A (zh) * 2021-09-09 2021-12-07 安徽师范大学 一种基于双区块链的医疗数据管理系统、病人授权病历共享方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106878071A (zh) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 一种基于Raft算法的区块链共识机制
CN107577694A (zh) * 2017-07-14 2018-01-12 阿里巴巴集团控股有限公司 一种基于区块链的数据处理方法及设备
CN108235799A (zh) * 2017-12-27 2018-06-29 深圳达闼科技控股有限公司 区块生成方法、装置、存储介质、区块链网络
US20200112443A1 (en) * 2018-10-04 2020-04-09 EMC IP Holding Company LLC Policy-driven dynamic consensus protocol selection
CN110598471A (zh) * 2019-09-17 2019-12-20 深圳市网心科技有限公司 基于区块链的时间戳生成方法、装置、系统及存储介质
CN111464356A (zh) * 2020-04-01 2020-07-28 腾讯科技（深圳）有限公司 一种区块共识周期切换方法、装置及计算机设备
CN112564960A (zh) * 2020-12-01 2021-03-26 浙商银行股份有限公司 基于区块链节点中心度弹性调整共识的方法及装置
CN113764060A (zh) * 2021-09-09 2021-12-07 安徽师范大学 一种基于双区块链的医疗数据管理系统、病人授权病历共享方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117478299A (zh) * 2023-12-27 2024-01-30 湖南天河国云科技有限公司 区块链共识算法切换方法、装置和计算机设备
CN117478299B (zh) * 2023-12-27 2024-03-01 湖南天河国云科技有限公司 区块链共识算法切换方法、装置和计算机设备

Also Published As

Publication number Publication date
CN116846888A (zh) 2023-10-03
US20230409450A1 (en) 2023-12-21

Similar Documents

Publication Publication Date Title
Li et al. An optimized byzantine fault tolerance algorithm for consortium blockchain
Meng et al. On consortium blockchain consistency: A queueing network model approach
Gupta et al. Blockchain transaction processing
Gupta et al. Resilientdb: Global scale resilient blockchain fabric
US20210256007A1 (en) Blockchain system and blockchain transaction data processing method based on ethereum
Amir et al. Steward: Scaling byzantine fault-tolerant replication to wide area networks
Wang et al. Mtmr: Ensuring mapreduce computation integrity with merkle tree-based verifications
CN112532396A (zh) 一种基于聚合签名的优化拜占庭容错方法及存储介质
Vizier et al. Comchain: Bridging the gap between public and consortium blockchains
Buchnik et al. Fireledger: A high throughput blockchain consensus protocol
WO2023179056A1 (zh) 区块链网络的共识处理方法、装置、设备及存储介质、程序产品
CN114218612A (zh) 一种适用于联盟链高频交易场景的共识方法
WO2023040453A1 (zh) 一种交易信息处理方法及装置
WO2023035065A1 (en) Methods and systems for fast consensus within distributed ledgers
CN112395113A (zh) 实用拜占庭容错共识方法及装置、可读存储介质
WO2021045829A1 (en) Byzantine consensus without centralized ordering
Abraham et al. Optimal good-case latency for rotating leader synchronous bft
CN112766560B (zh) 联盟区块链网络优化方法、装置、系统和电子设备
Gupta et al. Reliable transactions in serverless-edge architecture
Berger et al. Sok: Scalability techniques for BFT consensus
Wu et al. Reinforced practical Byzantine fault tolerance consensus protocol for cyber physical systems
Saeed et al. Performance evaluation of E-voting based on hyperledger fabric blockchain platform
Xu et al. Curb: Trusted and scalable software-defined network control plane for edge computing
Yu et al. A blockchain communication resource optimization consensus method
CN114499874A (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: 22933107

Country of ref document: EP

Kind code of ref document: A1