CN116192407A - Consensus method and apparatus in a blockchain system - Google Patents
Consensus method and apparatus in a blockchain system Download PDFInfo
- Publication number
- CN116192407A CN116192407A CN202310255763.XA CN202310255763A CN116192407A CN 116192407 A CN116192407 A CN 116192407A CN 202310255763 A CN202310255763 A CN 202310255763A CN 116192407 A CN116192407 A CN 116192407A
- Authority
- CN
- China
- Prior art keywords
- node
- message
- preparation
- backup
- consensus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 77
- 238000002360 preparation method Methods 0.000 claims abstract description 109
- 230000004044 response Effects 0.000 claims abstract description 15
- 230000037452 priming Effects 0.000 claims 1
- 230000008569 process Effects 0.000 description 41
- 238000004422 calculation algorithm Methods 0.000 description 21
- 238000010586 diagram Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000003860 storage Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000011112 process operation Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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
-
- 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
Abstract
The application relates to a consensus method and device in a blockchain system. The method comprises the following steps: the method comprises the steps that a 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 preparation message and broadcasts the preparation message to the main node and all other backup nodes except the backup node; in response to receiving at least 2f consistent prepare messages and no view switch occurs, the primary node or the backup node performs the operation to be performed and sends a reply message to the client. Through the technical scheme of the application, the consensus efficiency of the distributed system can be improved.
Description
Technical Field
The present application relates generally to the field of blockchain technology, and more particularly, to a consensus method and apparatus in a blockchain system.
Background
The design of the distributed system cluster faces an unavoidable problem, namely, a consistency problem, and the consensus algorithm is a series of processes and rules generated for realizing the distributed consistency protocol. For a plurality of service nodes in the system, through a series of given operations, the global to local processing results can be consistent to a certain extent, so that each host can achieve safe and reliable state consensus.
The PBFT (Practical Byzantine Fault Tolerance) algorithm is a consensus algorithm widely applied in alliance chains, and reliability can be effectively ensured by adopting a three-stage consensus design. The alliance chain is only aimed at members of a specific group and limited third parties, and is often used for groups such as banks, insurance, business association, group enterprises, upstream and downstream enterprises and the like.
However, when the number of nodes is too large, the efficiency of the three-stage message forwarding in the algorithm process is greatly reduced, so that the time of each consensus process is doubled, and the efficiency of the consensus process of the whole distributed system in the actual operation process is lower, and therefore, how to improve the PBFT consensus algorithm and the consensus efficiency of the distributed system is a technical problem to be solved.
Disclosure of Invention
To solve the above technical problem in the prior art, the present application provides a consensus method in a blockchain system, wherein the blockchain system is used for executing a smart contract, the blockchain system includes a master node and a plurality of backup nodes, the total number of the master node and the backup nodes is m, which includes f problem nodes, wherein f=0, 1, 2, 3, & gt, m is a positive integer, the method includes: the master node receives a request message sent by a client, wherein the request message comprises an operation to be executed in the intelligent 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 comprises the request message and sequence numbers and summaries of the request message; each backup node generates a preparation message according to the preparation message and broadcasts the preparation message to the main node and all other backup nodes except the backup node, wherein the preparation message comprises the serial number and the abstract of the request message; in response to receiving at least 2f consistent preparation messages and no view switch occurs, the master node or the backup node performs the operation to be performed and sends a reply message to the client, wherein the consistent preparation messages refer to preparation messages containing sequence numbers and digests of request messages consistent with the sequence numbers and the digests in the pre-preparation messages of the master node or the backup node, and the view switch occurs when the master node is replaced.
In one embodiment, the performing the operation to be performed and sending a reply message to the client by the primary node or the backup node in response to receiving at least 2f consistent prepare messages and no view switch occurs comprises: in response to receiving at least 2f consistent prepare messages, the primary node or the backup node enters a ready-to-complete state; the master node or the backup node in the ready-to-complete state performs the operation to be performed and sends the reply message to the client.
In one embodiment, the method further comprises: responding to the view switching of the master node, stopping receiving preparation messages broadcast by other backup nodes by the backup node which does not enter the preparation completion state, and only receiving the preparation messages broadcast by the master node or the backup node in the preparation completion state; in response to receiving at least 2f consistent prepare messages, the backup node enters the ready-to-complete state.
In one embodiment, the receiving a preparation message broadcast by the primary node or the backup node in the ready-to-complete state includes: calculating the priority of the master node or the backup node in the preparation completion state; and preferentially receiving the preparation messages broadcast by the main node or the backup node with higher priority.
In one embodiment, the priority of the primary node or the backup node is
，
wherein ,
for the priority corresponding to the ith node in the ready-to-complete state, ++>
For the current and the node->
Total number of other nodes completing consensus, +.>
For the node->
Time taken from the start of receiving the pre-preparation message to the entry into the preparation completion state,/->
>0，/>
>0。
In one embodiment, the method further comprises: the node in the ready state continues to receive the ready messages sent by other backup nodes which have not entered the ready state, so as to increase the priority of the node.
In one embodiment, the receiving, by the master node, the request message sent by the client includes: the master node receives a plurality of request messages sent by a plurality of clients; the master node stores the plurality of request messages in a message queue and generates a sequence number for each request message.
In one embodiment, the master node generating a pre-prepare message from the request message comprises: the master node pulls a specific number of request messages from the message queue in a first-in-first-out manner; and the master node sequentially generates preparation messages for the request messages with the specific number according to the sequence numbers of the request messages.
In one embodiment, the request message further includes transaction data of the client, where the transaction data includes a signature of the client, contract invoking rights and contract validity, and the method further includes: verifying whether the transaction data in the request message is correct; pre-executing the operation to be executed to obtain a pre-execution result and pre-calculating a hash value of the transaction data in response to verifying that the transaction data in the request message is correct; storing the pre-execution result, the transaction data, and the hash value of the transaction data into a transaction table, wherein the transaction table is pre-configured for the smart contract.
According to a second aspect of the present application, there is also provided a consensus apparatus in a blockchain system, comprising a memory and a processor, the memory having stored thereon computer executable instructions that, when executed by the processor, implement a consensus method in a blockchain system according to the first aspect of the present application.
The technical scheme of the application has the following beneficial technical effects:
according to the technical scheme, the three consensus phases of the PBFT algorithm are combined and optimized, so that the functions of the three consensus phases can be realized through only two consensus phases, the situation that node interaction efficiency is low due to the existence of a plurality of consensus phases is effectively reduced, and the consensus efficiency of a distributed system in the process of applying the PBFT algorithm is improved; meanwhile, the time cost of the consensus process is reduced and the overtime probability is reduced by pre-processing the operation of part of the consensus process, so that the consensus efficiency of the distributed system is further improved.
Drawings
The above, as well as additional purposes, features, and advantages of exemplary embodiments of the present application will become readily apparent from the following detailed description when read in conjunction with the accompanying drawings. Several embodiments of the present application are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar or corresponding parts and in which:
FIG. 1 is a schematic diagram of a three-phase consensus process of a prior art PBFT algorithm;
FIG. 2 is a flow chart of a consensus method in a blockchain system in accordance with an embodiment of the present application;
FIG. 3 is a schematic diagram of a two-stage consensus process of a consensus method in a blockchain system in accordance with an embodiment of the present application;
fig. 4 is a schematic block diagram of a consensus device in a blockchain system in accordance with an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all, of the embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
It should be understood that when the terms "first," "second," and the like are used in the claims, specification, and drawings of this application, they are used merely for distinguishing between different objects and not for describing a particular sequential order. The terms "comprises" and "comprising," when used in the specification and claims of this application, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
According to a first aspect of the present application, there is provided a consensus method in a blockchain system. The consensus method of the application is improved aiming at the consensus process of the existing PBFT algorithm. FIG. 1 is a schematic diagram of a three-phase consensus process of a prior art PBFT algorithm. As shown in fig. 1, C is a client, 0, 1, 2, and 3 are node members in the distributed system, 0 is a primary node, 1, and 2 are backup nodes, 3 is a backup node but has failed, and information sent by the default backup node 3 is invalid. The PBFT algorithm includes three core stages, a pre-prepare stage, a prepare stage, and a commit stage, respectively. Taking the distributed system as a blockchain system as an example, the consensus flow is as follows:
s1, selecting a master node (leader) from the whole network nodes, wherein the new area block is responsible for being generated by the master node.
S2, the master node sorts and stores a plurality of transactions which are collected from the network and need to be placed in the new area into a list, and broadcasts the list to the whole network.
S3, after each node receives the transaction list, executing the transactions according to the sequencing simulation. After all the transactions are executed, calculating the hash abstract of the new block based on the transaction result, and broadcasting the hash abstract to the whole network.
S4, if the abstracts sent by 2f (f is the tolerable Bayesian node number) other nodes received by one node are equal to the abstracts sent by the other nodes, broadcasting a commit message to the whole network.
S5, if one node receives 2f+1 commit messages, the new block and the transaction thereof can be submitted to a local blockchain and state database.
When the number of nodes is too large, the efficiency of the three-section message forwarding in the consensus process of the algorithm can be greatly reduced, so that the time of each consensus process is doubled, the cost is high, and the efficiency is low.
Fig. 2 is a flow chart of a consensus method in a blockchain system in accordance with an embodiment of the present application. The blockchain system is used for executing intelligent contracts. The intelligent contract is characterized in that according to the programmable characteristic of the blockchain, the contract in reality is put on the blockchain in the form of codes and is automatically executed under the contracted condition. The blockchain system includes a master node and a plurality of backup nodes, the total number of the master node and the backup nodes is m, including f problem nodes, wherein f=0, 1, 2, 3. As shown in fig. 2, the consensus method includes steps S201 to S204, which are described in detail below in connection with fig. 3. Fig. 3 is a schematic diagram of a two-stage consensus process of a consensus method in a blockchain system in accordance with an embodiment of the present application. The blockchain system in fig. 3 is identical in composition to the blockchain system in fig. 1, and also includes a primary node 0 and backup nodes 1, 2, 3, wherein backup node 3 is a problem node. The master node is responsible for packaging transaction data into blocks and block consensus, each round of consensus has only one master node, the backup node is responsible for block consensus, a plurality of backup nodes are arranged in each round of consensus, and the processing process of each backup node is similar. The main node and the backup node belong to a common node, and the common node can be a normal node or a faulty node or a disqualified node.
It should be noted that, in the following description, differences between the algorithm of the present application and the existing PBFT algorithm are mainly described, and details of the differences between the algorithm of the present application and the existing PBFT algorithm are not described in detail, and specific details related to the existing PBFT algorithm may be referred to and will not be described herein.
S201, the master node receives a request message sent by a client, wherein the request message comprises an operation to be executed in the intelligent contract.
The request message is denoted as m, and the operations to be performed included in the request message may be one or more operations in the smart contract, such as calling a certain contract function.
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 comprises the request message and sequence numbers and digests of the request message.
The master node sends the preprocessed request message as a PRE-PREPARE message to other backup nodes, where the PRE-PREPARE message may be in a specific form of < < pre_prepare, v, n, d, m >, where v represents a view number (the view number is a specific number of the current master node, and the current master node is a, the view number is 1, if the master node is changed to B, the view number is 2), n represents a sequence number (each request received by the master node is marked with a number), d represents a message digest, and m represents original message data.
The backup node performs message verification after receiving the pre-preparation message, where the message verification includes:
1) Verifying the signature legitimacy of the message m, and verifying whether the message digest d and the message m match: d=hash (m);
2) Verifying whether the node is currently in view v;
3) Verifying whether other pre-prepared messages exist on the same view v and sequence number n at present, because the master node cannot send two messages with the same v and n but different d and m;
it should be noted that, the above process is consistent with the pre-preparation stage of the existing PBFT algorithm, when the verification is passed, the current backup node agrees to the client request sent by the master node, and if the verification is not passed, the client request sent by the master node is rejected.
S203, each backup node generates a preparation message according to the preparation message and broadcasts the preparation message to the master node and all other backup nodes except the backup node, wherein the preparation message includes the sequence number and the digest of the request message.
Specifically, after the backup node agrees to the client request, a preparation message is sent to other backup nodes, where the specific form of the preparation message may be < PREPARE, v, n, d, i >, and the preparation message is recorded in a log, where i is used to indicate the identity of the current backup node. Wherein the current backup node is any one of the backup nodes.
In this alternative embodiment, since more than one backup node is performing the process of sending the prepare message at the same time, the current backup node may also receive the prepare message sent from other backup nodes. The current backup node i verifies whether v, n, d data of the preparation messages and the preparation messages sent by the current backup node i are consistent, and after verification is passed, the current backup node i marks the state of the current backup node i as ready (m, v, n, i, j) for indicating that the current backup node i and the backup node j agree on the preparation message of the message m in (v, n).
And S204, 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, wherein the consistent preparation messages refer to preparation messages of which the sequence numbers and summaries of the contained request messages are consistent with the sequence numbers and the summaries in the pre-preparation messages of the master node or the backup node, and the view switching occurs when the master node is replaced.
Specifically, the responding to receiving at least 2f consistent preparation messages and no view switching occurs, the master node or the backup node executing the operation to be executed and sending a reply message to the client comprises: in response to receiving at least 2f consistent prepare messages, the primary node or the backup node enters a ready-to-complete state; the master node or the backup node in the ready-to-complete state performs the operation to be performed and sends the reply message to the client.
When the current backup node verifies that more than 2f preparation messages sent by other backup nodes are received and that these preparation messages agree with the own preparation messages, it is stated that the preparation (preparation) phase of the current backup node has been completed. In the scheme, the state of the current backup node which has completed the preparation stage is marked as preparation completion (prepared-true), and the preparation message sent by the current backup node is marked as preparation completion message.
It should be noted that, in the normal PBFT consensus process, if the master node is not a problem node, the commit (commit) stage is not needed in practice, because the current backup node, in addition to itself, can ensure that there are at least 2f+1 consensus nodes to be agreed, even if there are f problem nodes, there are still f+1 normal nodes to receive correct results, so that finally, all nodes can successfully reach the consensus conclusion. Thus, in this case, the consensus process has been completed, so the master node or the backup node that has entered the ready-to-complete state performs the operation to be performed and sends a reply message to the client.
However, if the master node is a problem node and thus a view switch occurs, that is, the master node is replaced, the current consensus process must be verified in the commit phase to be performed smoothly. The reason is that the consensus process of the PBFT algorithm is a weak synchronization process, the preparation messages of the current backup node cannot be timely and synchronously sent to other nodes, when the current backup node has reached the preparation completion state, the other nodes may not receive enough preparation messages for network reasons, so that the preparation completion state is not reached yet, at this time, if the master node is replaced, a new master node initiates a new round of consensus, at this time, the other nodes perform consensus on the messages sent by the new master node, so that execution results different from those of the current backup node are caused.
Illustratively, there are 9 nodes in the current distributed system, node a to node I, where node a to node F are normal nodes, node G, H, I is an abnormal node, and if there is no commit phase, node a executes message m corresponding to number n after reaching the ready state, but none of node B to node F reaches the ready state. However, if no measure is taken at this point, the new master node may not know that number n already corresponds to message m (or the new master node is a malicious node, provided that it does not know that number n already corresponds to message m), and then the new master node initiates message m 'corresponding to number n, node B to node F will agree on new message m', resulting in a different execution result than in node a.
In order to ensure that the consensus process is normally performed when a master node view switch occurs, the method further comprises: responding to the view switching of the master node, stopping receiving preparation messages broadcast by other backup nodes by the backup node which does not enter the preparation completion state, and only receiving the preparation messages broadcast by the master node or the backup node in the preparation completion state; in response to receiving at least 2f consistent prepare messages, the backup node enters the ready-to-complete state.
In particular, in the case of the de-commit phase, it must be ensured that in the PBFT consensus phase, as long as a certain correct node performs a transaction, the other correct nodes must also perform the transaction. I.e. when a message with the number n is executed in the normal node a, the message must also be executed in the normal node B, and the execution number n, the node B must execute the message m with the number n even if the node a has performed a handover of the master node after executing the message m.
In the scheme, after the submitting stage of the PBFT is removed, the consensus process of each node is adjusted in the preparation stage, and the specific process is as follows: after the nodes reach the preparation completion state, other nodes which have not entered the preparation completion state no longer receive the preparation messages sent by the nodes which have not entered the preparation completion state, namely when the nodes which have entered the preparation completion state begin to appear in the distributed system, all the nodes which have not entered the preparation completion state only receive and forward the preparation completion messages.
In this alternative embodiment, since the node that has entered the ready state has completed the consensus process with other nodes, the other nodes that have not entered the ready state can indirectly complete the consensus process with other nodes only by consensus with the node that has entered the ready state, so that the problems of increased system load and lower consensus efficiency caused by a large number of forwarding messages between nodes when the nodes of the distributed system are too many are avoided. Meanwhile, all nodes which do not enter the preparation completion state at this time only receive messages from the nodes which are in the preparation completion state, so that even if the master node changes in the consensus process, the normal operation of the current consensus process can be ensured, and the current consensus message is ensured to be executed by other normal nodes after the master node is switched.
In order to further enhance the reliability of the consensus process and to increase the efficiency of the consensus process, the inventors have made further optimization of the consensus process described above. Specifically, the receiving the preparation message broadcast by the primary 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 messages broadcast by the main node or the backup node with higher priority.
Although the message sent by the node in the preparation completion state is commonly known and cannot be forged, some problematic nodes may maliciously miss the preparation completion message in the process of sending the message, or the node in the preparation completion state currently may crash and downtime due to external reasons, so in the scheme, the priority of each node in the preparation completion state is sequenced from high to low by calculating the priority of each node in the preparation completion state, and accordingly, the continuous and efficient operation of the whole commonly known process is ensured under the condition that the preparation completion message with higher priority is missed or the node marked as preparation completion currently cannot operate.
As an example, the priority of the primary node or the backup node is
，
wherein ,
for the priority corresponding to the ith node in the ready-to-complete state, ++>
For the current and the node->
Total number of other nodes completing consensus, +.>
For the node->
Time taken from the start of receiving the pre-preparation message to the entry into the preparation completion state,/->
>0，/>
>0。
The above relation ensures that the node enters the ready state earlier, the corresponding priority is higher, and the priority of the node is higher as the total number of other nodes which are commonly known with the node is higher. Furthermore, by the aboveThe relation can also ensure
The smaller the priority of the corresponding node i increases faster, with +.>
The priority of the corresponding node i increases more and more slowly, and finally tends to be gentle and not to increase any more, because the node in the preparation completion state is more important when the node is started to enter the preparation completion state in the scheme, and the node in the preparation completion state is not required to send a message to other nodes after a period of time is elapsed, so that the efficient implementation of the consensus process at the first time is facilitated.
In the above process, the node entering the ready state may notify the other nodes themselves that it has entered the ready state through a broadcast message, and periodically broadcast its own priority in a subsequent process, so that the other nodes in the blockchain system may know their actual states and determine the corresponding operations.
It should be noted that, the node in the ready state may further receive the ready message sent by the other node, so as to further increase the reliability of the current node in the ready state in the consensus process, that is, the more nodes participating in the consensus, the higher the reliability of the consensus result. Accordingly, the method further comprises: the node in the ready state continues to receive the ready messages sent by other backup nodes which have not entered the ready state, so as to increase the priority of the node.
In summary, by combining and optimizing the three consensus phases of the PBFT algorithm, the scheme realizes the function and effect of the three consensus phases only through two consensus phases, thereby effectively reducing the situation of low node interaction efficiency caused by the existence of a plurality of consensus phases, and improving the consensus efficiency of the distributed system in the process of applying the PBFT algorithm.
As a further optimization of the technical solution of the present application, the receiving, by the master node, the request message sent by the client includes: the master node receives a plurality of request messages sent by a plurality of clients; the master node stores the plurality of request messages in a message queue and generates a sequence number for each request message.
Correspondingly, the master node generating a pre-preparation message according to the request message comprises: the master node pulls a specific number of request messages from the message queue in a first-in-first-out manner; and the master node sequentially generates preparation messages for the request messages with the specific number according to the sequence numbers of the request messages.
Further, the request message further includes transaction data of the client, where the transaction data includes a signature of the client, contract invoking authority, and contract validity, and the method further includes: verifying whether the transaction data in the request message is correct; pre-executing the operation to be executed to obtain a pre-execution result and pre-calculating a hash value of the transaction data in response to verifying that the transaction data in the request message is correct; storing the pre-execution result, the transaction data, and the hash value of the transaction data into a transaction table, wherein the transaction table is pre-configured for the smart contract.
Specifically, the master node performs preprocessing on the received client messages, including caching the client messages received by the master node by configuring a cache cluster, and storing all the client messages in a message queue, because the master node may receive a large amount of messages from a plurality of clients in a short time, and the messages are difficult to be processed simultaneously by the master node in a short time, so that the master node can conveniently pull the messages in normal quantity in sequence for processing through the message queue, thereby realizing message peak clipping, and preventing transaction loss caused by excessive load of the master node and causing common recognition failure.
When the master node pulls the client message from the message queue for processing, the master node firstly verifies whether transaction data such as client signature, contract calling authority, contract validity and the like in the client message are correct, pre-executes hash values of intelligent contracts and pre-calculated transaction data after verification is successful, and then stores current transaction data, execution results and calculation results into the transaction table, so that partial consensus process operation can be pre-processed, time cost of the consensus process is reduced, overtime probability is reduced, and consensus efficiency of the distributed system is further improved.
According to a second aspect of the present application, there is also provided an consensus apparatus in a blockchain system. Fig. 4 is a schematic block diagram of a consensus device in a blockchain system in accordance with an embodiment of the present application. As shown in fig. 4, the apparatus 400 includes a processor and a memory storing computer program instructions that when executed by the processor implement a consensus method in a blockchain system according to the first aspect of the present application. The device also includes other components, such as a communication bus and a communication interface, which are well known to those skilled in the art, and the arrangement and function of which are known in the art and therefore not described in detail herein.
In the context of this application, the foregoing memory may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, the computer readable storage medium may be any suitable magnetic or magneto-optical storage medium, such as, for example, resistance change Memory RRAM (Resistive Random Access Memory), dynamic Random Access Memory DRAM (Dynamic Random Access Memory), static Random Access Memory SRAM (Static Random-Access Memory), enhanced dynamic Random Access Memory EDRAM (Enhanced Dynamic Random Access Memory), high-Bandwidth Memory HBM (High-Bandwidth Memory), hybrid storage cube HMC (Hybrid Memory Cube), etc., or any other medium that may be used to store the desired information and that may be accessed by an application, a module, or both. Any such computer storage media may be part of, or accessible by, or connectable to, the device. Any of the applications or modules described herein may be implemented using computer-readable/executable instructions that may be stored or otherwise maintained by such computer-readable media.
Those skilled in the art will also appreciate from the foregoing description of the present application that terms used herein such as "upper," "lower," and the like, which indicate an orientation or a positional relationship, are based on the orientation or positional relationship shown in the drawings of the present application, are for convenience only in describing aspects of the present application and simplifying the description, and do not explicitly or implicitly refer to devices or elements that must have the particular orientation, be constructed and operate in the particular orientation, and therefore the above orientation or positional relationship terms should not be interpreted or construed as limiting aspects of the present application.
The technical features of the above-described embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above-described embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The above examples only represent a few embodiments of the present application, which are described in more detail and are not to be construed as limiting the scope of the claims. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application is to be determined by the claims appended hereto.
Claims (10)
1. A consensus method in a blockchain system, wherein the blockchain system is used to execute a smart contract, the blockchain system comprising a master node and a plurality of backup nodes, the total number of master nodes and backup nodes being m, wherein f question nodes are included, wherein f = 0, 1, 2, 3,..m is a positive integer, the method comprising:
the master node receives a request message sent by a client, wherein the request message comprises an operation to be executed in the intelligent 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 comprises the request message and sequence numbers and summaries of the request message;
each backup node generates a preparation message according to the preparation message and broadcasts the preparation message to the main node and all other backup nodes except the backup node, wherein the preparation message comprises the serial number and the abstract of the request message;
in response to receiving at least 2f consistent preparation messages and no view switch occurs, the master node or the backup node performs the operation to be performed and sends a reply message to the client, wherein the consistent preparation messages refer to preparation messages containing sequence numbers and digests of request messages consistent with the sequence numbers and the digests in the pre-preparation messages of the master node or the backup node, and the view switch occurs when the master node is replaced.
2. The method of consensus in a blockchain system according to claim 1, wherein the master node or the backup node performing the operation to be performed and sending a reply message to the client in response to receiving at least 2f consistent prepare messages and no view switch occurs comprises:
in response to receiving at least 2f consistent prepare messages, the primary node or the backup node enters a ready-to-complete state;
the master node or the backup node in the ready-to-complete state performs the operation to be performed and sends the reply message to the client.
3. The consensus method in a blockchain system according to claim 2, wherein the method further comprises:
responding to the view switching of the master node, stopping receiving preparation messages broadcast by other backup nodes by the backup node which does not enter the preparation completion state, and only receiving the preparation messages broadcast by the master node or the backup node in the preparation completion state;
in response to receiving at least 2f consistent prepare messages, the backup node enters the ready-to-complete state.
4. The method of consensus in a blockchain system according to claim 3, wherein the receiving a prepare message broadcast by the primary node or the backup node in the ready-to-complete state comprises:
calculating the priority of the master node or the backup node in the preparation completion state;
and preferentially receiving the preparation messages broadcast by the main node or the backup node with higher priority.
5. A method of consensus in a blockchain system according to claim 3 and wherein the priority of the primary node or the backup node is
，
wherein ,
for the priority corresponding to the ith node in the ready-to-complete state, ++>
For the current and the node->
Total number of other nodes completing consensus, +.>
For the node->
From receiving the saidTime taken for the pre-prepare message to start to enter the ready-to-complete state, +.>
>0，/>
>0。
6. The method of consensus in a blockchain system according to claim 5, further comprising: the node in the ready state continues to receive the ready messages sent by other backup nodes which have not entered the ready state, so as to increase the priority of the node.
7. The method of consensus in a blockchain system according to claim 1, wherein the master node receiving a request message sent by a client comprises:
the master node receives a plurality of request messages sent by a plurality of clients;
the master node stores the plurality of request messages in a message queue and generates a sequence number for each request message.
8. The method of consensus in a blockchain system according to claim 7, wherein the master node generating a priming message from the request message comprises:
the master node pulls a specific number of request messages from the message queue in a first-in-first-out manner;
and the master node sequentially generates preparation messages for the request messages with the specific number according to the sequence numbers of the request messages.
9. The method of consensus in a blockchain system according to claim 8, wherein the request message further includes transaction data for the client, wherein the transaction data includes a signature of the client, contract invocation authority, and contract validity, the method further comprising:
verifying whether the transaction data in the request message is correct;
pre-executing the operation to be executed to obtain a pre-execution result and pre-calculating a hash value of the transaction data in response to verifying that the transaction data in the request message is correct;
storing the pre-execution result, the transaction data, and the hash value of the transaction data into a transaction table, wherein the transaction table is pre-configured for the smart contract.
10. A consensus means in a blockchain system comprising a memory and a processor, the memory having stored thereon computer executable instructions that when executed by the processor implement a consensus method in a blockchain system according to any of claims 1 to 9.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310233540 | 2023-03-13 | ||
| CN2023102335403 | 2023-03-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116192407A true CN116192407A (en) | 2023-05-30 |
Family
ID=86447444
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310255763.XA Pending CN116192407A (en) | 2023-03-13 | 2023-03-16 | Consensus method and apparatus in a blockchain system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116192407A (en) |
-
2023
- 2023-03-16 CN CN202310255763.XA patent/CN116192407A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11095750B2 (en) | Method, apparatus, and electronic device for processing consensus requests in a blockchain consensus network | |
| EP3934165B1 (en) | Consensus method of consortium blockchain, and consortium blockchain system | |
| CN109886681B (en) | Block chain consensus method and system | |
| US20210256007A1 (en) | Blockchain system and blockchain transaction data processing method based on ethereum | |
| CN109189751B (en) | Data synchronization method based on block chain and terminal equipment | |
| EP3934162B1 (en) | Blockchain consensus method and device and electronic equipment | |
| US11385830B2 (en) | Data storage method, apparatus and system, and server, control node and medium | |
| CN111475576B (en) | Block chain-based distributed database storage method and system | |
| WO2021244568A1 (en) | Method for consensus in blockchain, and system | |
| CN105930498A (en) | Distributed database management method and system | |
| TW202037122A (en) | Consensus system downtime recovery | |
| CN105988862A (en) | Distributed transaction processing method and device | |
| CN115665170B (en) | Block chain consensus method based on reputation and node compression mechanism | |
| CN114218612A (en) | Consensus method suitable for high-frequency trading scene of alliance chain | |
| CN110460484A (en) | A kind of single node exception active restoration methods based on PBFT algorithm improvement | |
| CN111311254A (en) | Service processing method, device and system based on block chain | |
| CN114936253A (en) | Block chain consensus method and device, electronic equipment and storage medium | |
| US20210218827A1 (en) | Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment | |
| CN111526165B (en) | Consensus method and system in alliance chain | |
| CN111131329A (en) | Data consensus method and device for block chain system and hardware equipment | |
| CN116192407A (en) | Consensus method and apparatus in a blockchain system | |
| CN116846888A (en) | Consensus processing method, device, equipment and storage medium of block chain network | |
| CN113760519A (en) | Distributed transaction processing method, device and system and electronic equipment | |
| CN113704813A (en) | Maritime work equipment secondary identification data storage method and system, and verification method and system | |
| Kang et al. | Blockchain-based High-reliability Recovery and Verification Mechanism for Power Data Storage Nodes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |