Consensus method and device in blockchain system

Abstract

The present application relates to a consensus method and device in a blockchain system. The method includes: the master node receives a request message sent by a client; the master node generates a pre-preparation message according to the request message and broadcasts the pre-preparation message to all the backup nodes; each backup node generates a preparation message according to the pre-preparation message and broadcasts the preparation message to the master node and all other backup nodes except the backup node; in response to receiving at least 2f consistent preparation messages and no view switching occurs, the master node or the backup node executes the operation to be executed and sends a reply message to the client. Through the technical solution of the present application, the consensus efficiency of the distributed system can be improved.

Description

Technical Field

[0001] The present application generally relates to the field of blockchain technology, and more particularly to a consensus method and device in a blockchain system. Background Art

[0002] Distributed system cluster design faces an unavoidable problem, namely the consistency problem, and the consensus algorithm is a series of processes and rules generated to implement the distributed consistency protocol. For multiple service nodes in the system, by giving a series of operations, the global consensus on the local processing results can be achieved to a certain extent, ensuring that each host reaches a safe and reliable state consensus.

[0003] The PBFT (Practical Byzantine Fault Tolerance) algorithm is a consensus algorithm widely used in consortium chains. It adopts a three-stage consensus design and can effectively ensure reliability. Among them, consortium chains are only for members of a specific group and limited third parties, and are often used in groups such as banks, insurance companies, business associations, group companies, and upstream and downstream companies.

[0004] However, when the number of nodes is too large, the three-stage message forwarding in the algorithm will greatly reduce efficiency, causing the time of each consensus process to double, resulting in low efficiency of the consensus process of the entire distributed system during actual operation. Therefore, how to improve the PBFT consensus algorithm to improve the consensus efficiency of the distributed system is a technical problem that needs to be solved. Summary of the invention

[0005] In order to solve the above technical problems in the prior art, the present application provides a consensus method in a blockchain system, wherein the blockchain system is used to execute smart contracts, the blockchain system includes a master node and multiple backup nodes, the total number of the master node and the backup node is m, including f problem nodes, where f = 0, 1, 2, 3,..., m is a positive integer, and the method comprises: the master node receives a request message sent by the client, wherein the request message includes the operation to be executed in the smart contract; the master node generates a pre-prepare message according to the request message and broadcasts the pre-prepare message to all the backup nodes, wherein the pre-prepare message includes the request message and the sequence number and digest of the request message; each backup node generates a prepare message according to the pre-prepare message and broadcasts the prepare message to the master node and all other backup nodes except the backup node, wherein the prepare message includes the sequence number and the digest of the request message; in response to receiving at least 2f consistent prepare messages and no view switching occurs, the master node or the backup node executes the operation to be executed and sends a reply message to the client, wherein the consistent prepare message refers to a prepare message whose sequence number and digest of the request message contained therein are consistent with the sequence number and the digest in the pre-prepare message of the master node or the backup node, and the view switching occurs when the master node is replaced.

[0006] In one embodiment, in response to receiving at least 2f consistent prepare messages and no view switching occurs, the primary node or the backup node executes the operation to be executed and sends a reply message to the client, including: in response to receiving at least 2f consistent prepare messages, the primary node or the backup node enters a preparation complete state; the primary node or the backup node in the preparation complete state executes the operation to be executed and sends the reply message to the client.

[0007] In one embodiment, the method further includes: in response to the view switch occurring at the master node, the backup node that has not yet entered the ready state stops receiving the ready messages broadcast by other backup nodes, and only receives the ready messages broadcast by the master node or the backup node that is in the ready state; in response to receiving at least 2f consistent ready messages, the backup node enters the ready state.

[0008] In one embodiment, the receiving of the preparation message broadcast by the master node or the backup node in the preparation completion state includes: calculating the priority of the master node or the backup node in the preparation completion state; and preferentially receiving the preparation message broadcast by the master node or the backup node with a higher priority.

[0009] In one embodiment, the priority of the master node or the backup node is ,

[0010]

[0011] in, is the priority corresponding to the i-th node in the ready state, For the current node The total number of other nodes that have completed consensus, For the node The time taken from receiving the pre-prepare message to entering the preparation complete state, >0, >0.

[0012] In one embodiment, the method further includes: the node that is already in the preparation completion state continues to receive preparation messages sent by other backup nodes that have not yet entered the preparation completion state, so as to increase the priority of the node.

[0013] In one embodiment, the master node receiving a request message sent by a client includes: the master node receiving multiple request messages sent by multiple clients; the master node storing the multiple request messages in a message queue and generating a sequence number for each request message.

[0014] In one embodiment, the master node generates a pre-prepared message based on the request message, including: the master node pulls a specific number of request messages from the message queue in a first-in-first-out manner; the master node generates pre-prepared messages for the specific number of request messages in sequence according to the sequence numbers of the request messages.

[0015] In one embodiment, the request message also includes transaction data of the client, wherein the transaction data includes the signature of the client, contract call authority and contract validity, and the method also includes: verifying whether the transaction data in the request message is correct; in response to verifying that the transaction data in the request message is correct, pre-executing the to-be-executed operation to obtain a pre-execution result, and pre-calculating a hash value of the transaction data; storing the pre-execution result, the transaction data and the hash value of the transaction data in a transaction table, wherein the transaction table is pre-configured for the smart contract.

[0016] According to the second aspect of the present application, a consensus device in a blockchain system is also provided, including a memory and a processor, wherein the memory stores computer executable instructions, and when the computer executable instructions are executed by the processor, the consensus method in the blockchain system according to the first aspect of the present application is implemented.

[0017] The technical solution of this application has the following beneficial technical effects:

[0018] The technical solution of the present application combines and optimizes the three consensus stages of the PBFT algorithm, so that the functions of the three consensus stages can be realized through only two consensus stages, thereby effectively reducing the low node interaction efficiency caused by the existence of multiple consensus stages, and improving the consensus efficiency of the distributed system in the process of applying the PBFT algorithm; at the same time, by pre-processing some consensus process operations, the time spent in the consensus process is reduced, and the probability of timeout is reduced, thereby further improving the consensus efficiency of the distributed system. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] By reading the detailed description below with reference to the accompanying drawings, the above and other purposes, features and advantages of the exemplary embodiments of the present application will become easy to understand. In the accompanying drawings, several embodiments of the present application are shown in an exemplary and non-limiting manner, and the same or corresponding reference numerals represent the same or corresponding parts, wherein:

[0020] Figure 1 This is a schematic diagram of the three-stage consensus process of the existing PBFT algorithm;

[0021] Figure 2 is a flow chart of a consensus method in a blockchain system according to an embodiment of the present application;

[0022] Figure 3 It is a schematic diagram of a two-stage consensus process of a consensus method in a blockchain system according to an embodiment of the present application;

[0023] Figure 4 It is a schematic block diagram of a consensus device in a blockchain system according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0025] It should be understood that when the terms "first", "second", etc. are used in the claims, specification and drawings of the present application, they are only used to distinguish different objects, rather than to describe a specific order. The terms "include" and "comprise" used in the specification and claims of the present application indicate the presence of the described features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or their collections.

[0026] According to the first aspect of the present application, the present application provides a consensus method in a blockchain system. The consensus method of the present application improves the consensus process of the existing PBFT algorithm. Figure 1 This is a schematic diagram of the three-stage consensus process of the existing PBFT algorithm. Figure 1 As shown, C is the client, 0, 1, 2, and 3 are node members in the distributed system, 0 is the primary node, 1 and 2 are backup nodes, and 3 is also a backup node but has failed. By default, the information sent by backup node 3 is invalid. The PBFT algorithm includes three core stages, namely the pre-prepare stage, the prepare stage, and the commit stage. Taking the distributed system as a blockchain system as an example, the consensus process is as follows:

[0027] S1. A leader is elected from all nodes in the entire network, and the leader is responsible for generating new blocks.

[0028] S2. The master node collects multiple transactions that need to be included in the new block from the network, sorts them, stores them in a list, and broadcasts the list to the entire network.

[0029] S3. After receiving the transaction list, each node simulates and executes these transactions according to the order. After all transactions are executed, the hash summary of the new block is calculated based on the transaction results and broadcast to the entire network.

[0030] S4. If a node receives summaries from 2f (f is the tolerable number of Byzantine nodes) other nodes that are equal to its own, it broadcasts a commit message to the entire network.

[0031] S5. If a node receives 2f+1 commit messages, it can submit the new block and its transactions to the local blockchain and status database.

[0032] When the number of nodes is too large, the three-stage message forwarding in the consensus process of the above algorithm will greatly reduce efficiency, making the time of each consensus process doubled, which is costly and inefficient.

[0033] Figure 2 This is a flowchart of the consensus method in the blockchain system according to the embodiment of the present application. The blockchain system is used to execute smart contracts. The smart contract is based on the programmable characteristics of the blockchain, which puts the real contract in the form of code on the blockchain and automatically executes under the agreed conditions. The blockchain system includes a master node and multiple backup nodes, the total number of the master node and the backup node is m, including f problem nodes, where f = 0, 1, 2,3, ..., m is a positive integer, m≥3f+1. Figure 2As shown, the consensus method includes steps S201 to S204. Figure 3 Specific instructions. Figure 3 It is a schematic diagram of a two-stage consensus process of a consensus method in a blockchain system according to an embodiment of the present application. Figure 3 The composition and Figure 1 The blockchain system is the same as that in the blockchain system, and also includes master node 0 and backup nodes 1, 2, and 3, among which backup node 3 is a problematic node. The master node is responsible for packaging transaction data into blocks and block consensus. There is only one master node in each round of consensus. The backup node is responsible for block consensus. There are multiple backup nodes in each round of consensus, and the processing process of each backup node is similar. Among them, the master node and the backup node are both consensus nodes, and the consensus node can be either a normal node or a problematic faulty node or a malicious node.

[0034] It should be noted that the following description focuses on the differences between the algorithm of the present application and the existing PBFT algorithm, and the similarities with the existing PBFT algorithm are not elaborated in detail. The relevant specific details can refer to the existing PBFT algorithm and will not be repeated here.

[0035] S201, the master node receives a request message sent by a client, wherein the request message includes an operation to be executed in the smart contract.

[0036] The request message is denoted as m, and the operations to be executed contained therein may be one or more operations in the smart contract, such as calling a certain contract function.

[0037] S202: The master node generates a pre-preparation message according to the request message and broadcasts the pre-preparation message to all the backup nodes, wherein the pre-preparation message includes the request message and a sequence number and a summary of the request message.

[0038] The master node sends the pre-processed request message as a pre-prepare message to other backup nodes. The specific form of the pre-prepare message can be <<PRE_PREPARE,v,n,d> ,m>, where v represents the view number (the view number is the exclusive number of the current master node. For example, the current master node is A, the view number is 1, and if the master node is changed to B, the view number is 2), n represents the sequence number (each request received by the master node from the client is marked with a number), d represents the message digest, and m represents the original message data.

[0039] After receiving the pre-preparation message, the backup node performs message verification, and the message verification includes:

[0040] 1) Verify the legitimacy of the signature of message m, and verify whether the message digest d and message m match: d=hash(m);

[0041] 2) Verify whether the node is currently in view v;

[0042] 3) Verify whether the node currently has other pre-prepared messages on the same view v and sequence number n, because the master node will not send two messages with the same v and n, but different d and m;

[0043] It is worth noting that the above process is consistent with the pre-preparation stage of the existing PBFT algorithm. When the above verification passes, the current backup node agrees to the client request sent by the primary node. If the verification fails, the client request sent by the primary node is rejected.

[0044] S203, each backup node generates a prepare message according to the pre-prepare message and broadcasts the prepare message to the master node and all other backup nodes except the backup node, wherein the prepare message includes the sequence number and the summary of the request message.

[0045] Specifically, after the backup node agrees to the client request, it will send a prepare message to other backup nodes. The specific form of the prepare message can be<PREPARE,v,n,d,i> , and the preparation message is recorded in the log, i is used to represent the identity of the current backup node. Wherein, the current backup node is any one of the backup nodes.

[0046] In this optional embodiment, since more than one backup node is sending a prepare message at the same time, the current backup node may also receive prepare messages sent by other backup nodes. The current backup node i verifies whether the v, n, d data of these prepare messages are consistent with the prepare message sent by itself. When the verification is passed, the current backup node i marks its own status as prepared (m, v, n, i, j), which is used to indicate that the current backup node i and the backup node j have reached an agreement on the prepare message of message m in (v, n).

[0047] S204, in response to receiving at least 2f consistent prepare messages and no view switching occurs, the primary node or the backup node executes the operation to be executed and sends a reply message to the client, wherein the consistent prepare message refers to a prepare message in which the sequence number and the digest of the request message contained are consistent with the sequence number and the digest in the pre-prepare message of the primary node or the backup node, and the view switching occurs when the primary node is replaced.

[0048] Specifically, in response to receiving at least 2f consistent prepare messages and no view switching occurs, the primary node or the backup node executes the operation to be executed and sends a reply message to the client, including: in response to receiving at least 2f consistent prepare messages, the primary node or the backup node enters a preparation complete state; the primary node or the backup node in the preparation complete state executes the operation to be executed and sends the reply message to the client.

[0049] When the current backup node verifies that it has received more than 2f prepare messages sent by other backup nodes and these prepare messages are consistent with its own prepare message, it means that the prepare phase of the current backup node has been completed. In this solution, the status of the current backup node that has completed the prepare phase is marked as prepared-true, and the prepare message sent by the current backup node is marked as a prepare-complete message.

[0050] It is worth noting that in the normal PBFT consensus process, if the master node is not a problem node, there is actually no need to commit, because the current backup node plus itself can guarantee at least 2f+1 consensus nodes that have reached a consensus. Even if there are f problem nodes, there are still f+1 normal nodes that will receive the correct result, so that all nodes can eventually reach a consensus. Therefore, in this case, the consensus process has been completed, so the master node or backup node that has entered the ready-to-complete state executes the pending operation and sends a reply message to the client.

[0051] However, if the master node is a problem node and a view switch occurs, that is, the master node is replaced, the verification in the submission phase must be performed to ensure the smooth progress of the current consensus process. The reason is that the consensus process of the PBFT algorithm is a weak synchronization process. The preparation message of the current backup node cannot be sent to other nodes in a timely and synchronous manner. When the current backup node has reached the ready state, other nodes may not receive enough preparation messages due to network reasons, and thus have not yet reached the ready state. At this time, if the master node is replaced, the new master node will initiate a new round of consensus. At this time, other nodes will reach consensus on the messages sent by the new master node, resulting in different execution results from the current backup node.

[0052] For example, there are 9 nodes in the current distributed system, from node A to node I, where nodes A to node F are normal nodes, and nodes G, H, and I are abnormal nodes. Assuming that there is no commit phase, node A executes message m corresponding to number n after reaching the ready state, but at this time, nodes B to node F have not reached the ready state. However, at this time, the master node switches. If no measures are taken, the new master node may not know that number n has corresponded to message m (or the new master node is a malicious node, pretending that it does not know that number n has corresponded to message m), so the new master node initiates message m' corresponding to number n, then nodes B to node F will reach consensus on the new message m', thereby obtaining an execution result different from that in node A.

[0053] In order to ensure the normal progress of the consensus process when a view switch of the master node occurs, the method also includes: in response to the view switch of the master node, the backup node that has not yet entered the ready state stops receiving the ready messages broadcast by other backup nodes, and only receives the ready messages broadcast by the master node or the backup node in the ready state; in response to receiving at least 2f consistent ready messages, the backup node enters the ready state.

[0054] Specifically, when the commit phase is removed, it must be ensured that in the PBFT consensus phase, as long as a correct node executes a transaction, other correct nodes must also execute the transaction. That is, when a message numbered n is executed in a normal node A, then the message must also be executed in a normal node B, and the execution number is also n. Even if the master node is switched after node A executes message m, node B must still execute message m with number n.

[0055] In this solution, after removing the commit phase of PBFT, the consensus process of each node is adjusted in the preparation phase. The specific process is: when a node reaches the ready state, other nodes that have not yet entered the ready state will no longer receive the ready message sent by the nodes that have not yet entered the ready state. That is, when nodes that have entered the ready state begin to appear in the distributed system, all nodes that have not yet entered the ready state will only receive and forward the ready message.

[0056] In this optional embodiment, since the nodes that have entered the ready state have completed the consensus process with other nodes, other nodes that have not yet entered the ready state can indirectly complete the consensus process with other nodes only by reaching consensus with the nodes that have reached the ready state. This avoids the problem of increased system load and low consensus efficiency caused by a large number of forwarding messages between nodes when there are too many nodes in the distributed system. At the same time, since all nodes that have not yet entered the ready state will only receive messages from nodes that are already in the ready state, even if the master node changes during the consensus process, the normal progress of the current consensus process can be guaranteed, ensuring that the currently agreed message will also be executed by other normal nodes after switching the master node.

[0057] In order to further enhance the reliability of the consensus process and improve the efficiency of the consensus process, the inventors have further optimized the above consensus process. Specifically, the receiving of the preparation message broadcast by the master node or the backup node in the preparation completion state includes: calculating the priority of the master node or the backup node in the preparation completion state; and preferentially receiving the preparation message broadcast by the master node or the backup node with a higher priority.

[0058] Although the messages sent from the nodes in the ready state have been agreed upon and cannot be forged, some problematic nodes may maliciously omit the ready message in the process of sending the message, or the nodes currently in the ready state may crash due to external reasons. Therefore, this scheme calculates the priority of each node in the ready state to sort the nodes in the ready state from high to low priority, so as to ensure that when a high-priority ready message is omitted or the node currently marked as ready cannot run, it can be promptly replaced by other nodes in the ready state, thereby ensuring the continuous and efficient operation of the entire consensus process.

[0059] As an example, the priority of the master node or the backup node is ,

[0060]

[0061] in, is the priority corresponding to the i-th node in the ready state, For the current node The total number of other nodes that have completed consensus, For the node The time taken from receiving the pre-prepare message to entering the preparation complete state, >0, >0.

[0062] The above relationship ensures that the earlier a node enters the ready state, the higher its corresponding priority. At the same time, the more other nodes that reach consensus with the node, the higher its priority will be. The smaller it is, the faster the priority of the corresponding node i increases. As the priority of node i increases, it increases more and more slowly, and finally tends to be flat and no longer increases. The reason is that in this scheme, the node that enters the ready state at the beginning is more important. As time goes by, the node that finally enters the ready state after a period of time basically does not need to send messages to other nodes, which is conducive to the efficient implementation of the consensus process at the first time.

[0063] In the above process, the node that has entered the ready state can notify other nodes that it has entered the ready state through a broadcast message, and periodically broadcast its own priority in the subsequent process, so that other nodes in the blockchain system can know its real-time status and determine the corresponding operations.

[0064] It is worth noting that the node that is already in the ready state can continue to receive the ready messages sent from other nodes to further increase the credibility of the current node in the ready state in the consensus process, that is, the more nodes participating in the consensus, the higher the credibility of the consensus result. Accordingly, the method also includes: the node that is already in the ready state continues to receive the ready messages sent by other backup nodes that have not yet entered the ready state to increase the priority of the node.

[0065] In summary, the above scheme combines and optimizes the three consensus stages of the PBFT algorithm, achieving the functions and effects of the three consensus stages through only two consensus stages, thereby effectively reducing the low node interaction efficiency caused by the existence of multiple consensus stages, thereby improving the consensus efficiency of the distributed system in the process of applying the PBFT algorithm.

[0066] As a further optimization of the technical solution of the present application, the master node receives the request message sent by the client, including: the master node receives multiple request messages sent by multiple clients; the master node stores the multiple request messages in a message queue and generates a sequence number for each request message.

[0067] Correspondingly, the master node generates a pre-prepared message according to the request message, including: the master node pulls a specific number of request messages from the message queue in a first-in-first-out manner; the master node generates pre-prepared messages for the specific number of request messages in sequence according to the sequence numbers of the request messages.

[0068] Furthermore, the request message also includes transaction data of the client, wherein the transaction data includes the signature of the client, contract call authority and contract validity, and the method also includes: verifying whether the transaction data in the request message is correct; in response to verifying that the transaction data in the request message is correct, pre-executing the to-be-executed operation to obtain a pre-execution result, and pre-calculating a hash value of the transaction data; storing the pre-execution result, the transaction data and the hash value of the transaction data in a transaction table, wherein the transaction table is pre-configured for the smart contract.

[0069] Specifically, the master node pre-processes the received client messages, including caching the client messages received by the master node by configuring a cache cluster, and storing all client messages in a message queue. The reason is that the master node may receive a large number of messages from multiple clients in a short period of time, and these messages are difficult to be processed by the master node at the same time in a short period of time. Therefore, the message queue is used to facilitate the master node to pull a normal number of messages in sequence for processing, thereby achieving message peak shaving and preventing the loss of transactions due to excessive load on the master node, which may cause consensus failure.

[0070] When the master node pulls the client message from the message queue for processing, it will first verify whether the transaction data in the client message, such as the client signature, contract call authority, contract validity, etc., is correct, and after successful verification, it will pre-execute the smart contract and pre-calculate the hash value of the transaction data, and then store the current transaction data, execution results and calculation results in the transaction table. In this way, some consensus process operations can be pre-processed, thereby reducing the time spent on the consensus process, reducing the probability of timeout, and further improving the consensus efficiency of the distributed system.

[0071] According to the second aspect of the present application, the present application also provides a consensus device in a blockchain system. Figure 4 Schematic diagram of a consensus device in a blockchain system according to an embodiment of the present application. Figure 4 As shown, the device 400 includes a processor and a memory, and the memory stores computer program instructions. When the computer program instructions are executed by the processor, the consensus method in the blockchain system according to the first aspect of the present application is implemented. The device also includes other components well known to those skilled in the art, such as a communication bus and a communication interface, whose settings and functions are known in the art, so they are not repeated here.

[0072] In the present application, the aforementioned memory may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, apparatus or device. For example, a computer-readable storage medium may be any suitable magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory RRAM (Resistive Random Access Memory), a dynamic random access memory DRAM (Dynamic Random Access Memory), a static random access memory SRAM (Static Random-Access Memory), an enhanced dynamic random access memory EDRAM (Enhanced Dynamic Random Access Memory), a high-bandwidth memory HBM (High-Bandwidth Memory), a hybrid memory cube HMC (Hybrid Memory Cube), etc., or any other medium that can be used to store the required information and can be accessed by an application, a module, or both. Any such computer storage medium may be part of a device or accessible or connectable to a device. Any application or module described in this application may be implemented using computer-readable / executable instructions that may be stored or otherwise maintained by such a computer-readable medium.

[0073] According to the above description of this specification, those skilled in the art may also understand that the terms used below, such as "upper", "lower" and other terms indicating orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings of this specification, and are only for the purpose of facilitating the explanation of the scheme of the present application and simplifying the description, rather than explicitly or implicitly indicating that the device or element involved must have the specific orientation, be constructed and operated in a specific orientation. Therefore, the above-mentioned orientation or positional relationship terms cannot be understood or interpreted as limitations on the scheme of the present application.

[0074] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0075] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be construed as limiting the scope of the patent application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent application shall be subject to the attached claims.

Claims

1. A consensus method in a blockchain system, wherein the blockchain system is used to execute smart contracts, the blockchain system includes a master node and multiple backup nodes, the total number of the master node and the backup nodes is m, including f problem nodes, where f = 0, 1, 2, 3, ..., m is a positive integer, characterized in that, The method comprises: The master node receives a request message sent by the client, wherein the request message includes the operation to be executed in the smart contract; The master node generates a pre-preparation message according to the request message and broadcasts the pre-preparation message to all the backup nodes, wherein the pre-preparation message includes the request message and the sequence number and summary of the request message; Each backup node generates a prepare message according to the pre-prepare message and broadcasts the prepare message to the master node and all other backup nodes except the backup node, wherein the prepare message includes the sequence number and the digest of the request message; In response to receiving at least 2f consistent prepare messages and no view switching occurs, the primary node or the backup node executes the to-be-performed operation and sends a reply message to the client, wherein the consistent prepare message refers to a prepare message in which the sequence number and the digest of the request message contained are consistent with the sequence number and the digest in the pre-prepare message of the primary node or the backup node, and the view switching occurs when the primary node is replaced; In response to receiving at least 2f consistent preparation messages and no view switching occurs, the primary node or the backup node executes the operation to be executed and sends a reply message to the client, including: In response to receiving at least 2f consistent preparation messages, the primary node or the backup node enters a preparation complete state; The master node or the backup node in the ready state executes the operation to be executed and sends the reply message to the client; The method further comprises: In response to the view switching occurring at the master node, the backup nodes that have not yet entered the preparation completion state stop receiving preparation messages broadcasted by other backup nodes, and only receive preparation messages broadcasted by the master node or the backup node that is in the preparation completion state; In response to receiving at least 2f consistent prepare messages, the backup node enters the prepare complete state.

2. The consensus method in the blockchain system according to claim 1, characterized in that: The receiving of the preparation message broadcast by the master node or the backup node in the preparation completion state comprises: Calculating the priority of the master node or the backup node in the ready state; Prioritize receiving the preparation message broadcasted by the master node or backup node with a higher priority.

3. The consensus method in the blockchain system according to claim 1, characterized in that: The priority of the master node or the backup node is , in, is the priority corresponding to the i-th node in the ready state, For the current node The total number of other nodes that have completed consensus, For the node The time taken from receiving the pre-prepare message to entering the preparation complete state, >0, >

0.

4. The consensus method in the blockchain system according to claim 3, characterized in that: The method further includes: the node that is already in the preparation completion state continues to receive preparation messages sent by other backup nodes that have not yet entered the preparation completion state, so as to increase the priority of the node.

5. The consensus method in the blockchain system according to claim 1, characterized in that: The master node receives a request message sent by the client, including: The master node receives multiple request messages sent by multiple clients; The master node stores the multiple request messages in a message queue and generates a sequence number for each request message.

6. The consensus method in the blockchain system according to claim 5, characterized in that: The master node generating a pre-preparation message according to the request message includes: The master node pulls a specific number of request messages from the message queue in a first-in-first-out manner; The master node generates pre-preparation messages for the specific number of request messages in sequence according to the sequence numbers of the request messages.

7. The consensus method in the blockchain system according to claim 6, characterized in that: The request message also includes the transaction data of the client, wherein the transaction data includes the signature of the client, the contract call authority and the contract validity, and the method further includes: Verifying whether the transaction data in the request message is correct; In response to verifying that the transaction data in the request message is correct, pre-execute the to-be-executed operation to obtain a pre-execution result, and pre-calculate a hash value of the transaction data; The pre-execution result, the transaction data, and the hash value of the transaction data are stored in a transaction table, wherein the transaction table is preconfigured for the smart contract.

8. A consensus device in a blockchain system, comprising a memory and a processor, wherein the memory stores computer executable instructions, characterized in that: When the computer executable instructions are executed by the processor, the consensus method in the blockchain system according to any one of claims 1 to 7 is implemented.

Images