CN115622713A - Consensus method, device, terminal and storage medium - Google Patents
Consensus method, device, terminal and storage medium Download PDFInfo
- Publication number
- CN115622713A CN115622713A CN202211280956.2A CN202211280956A CN115622713A CN 115622713 A CN115622713 A CN 115622713A CN 202211280956 A CN202211280956 A CN 202211280956A CN 115622713 A CN115622713 A CN 115622713A
- Authority
- CN
- China
- Prior art keywords
- node
- block
- slave
- consensus
- transaction
- 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
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/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a consensus method, a consensus device, a terminal and a storage medium, wherein the method comprises the following steps: the main node receives the transaction sent by the first slave node, generates a block proposal corresponding to the transaction, generates a pre-submission block based on the block proposal and an endorsement signature of the first consensus node, and sends a submission request to the second slave node based on the pre-submission block and the confirmation information of the second consensus node, so that the second slave node submits the pre-submission block to the account book based on an account book synchronization mechanism. The invention not only greatly improves the efficiency of transaction endorsement by processing endorsements in batches, but also accelerates the block submitting speed by submitting the request of the block in advance without needing to carry out submission confirmation after the next block is output, thereby reducing the delay of transaction chaining and improving the service stability.
Description
Technical Field
The present application relates to the field of block chain technologies, and in particular, to a consensus method, apparatus, terminal, and storage medium.
Background
Block chains have many consensus methods, including byzantine fault-tolerant consensus methods for public chains, such as workload attestation (PoW) mechanisms, entitlement attestation (PoS) mechanisms, etc., and crash-tolerant and byzantine fault-tolerant consensus methods for federation chains, including Raft, PBFT, hot stuff, etc.
At present, the PoW consensus mechanism realizes Byzantine fault tolerance by improving the malicious cost, namely, the resources and the computing power consumed by mining and the block-out reward are used as the cost, the PoW consensus mechanism is adopted in most block chain items such as bitcoin and Ethengfang, and the effectiveness of the PoW consensus mechanism is proved by practice. PoS is used as a replacement scheme of PoW, mainly solves the problem of resource waste of PoW, and is a main research direction of a public chain consensus mechanism. The common recognition algorithm based on the Raft can realize breakdown fault tolerance, all blocks are sent out through the master node, each slave node passively receives the master node blocks, and a new master node can be reselected after the master node is broken down. The PBFT consensus algorithm realizes Byzantine fault tolerance of 1/3 nodes, and one block submission is completed through two rounds of majority node statistics in the prepare and commit stages, so that communication among all slave nodes is needed, communication complexity needed by the PBFT algorithm of safety and activity is guaranteed, and expansion of the PBFT algorithm to a large-scale network is limited.
However, the above-mentioned consensus method may cause block rollback due to chain branching and the like, thereby reducing the stability of the docking service.
Disclosure of Invention
The present application mainly aims to provide a consensus method, apparatus, terminal, and storage medium, so as to solve the problem of poor stability of a docking service in the related art.
To achieve the above object, in a first aspect, the present application provides a consensus method, comprising:
the method comprises the steps that a main node receives a transaction sent by a first slave node and generates a block proposal corresponding to the transaction, wherein the transaction is determined by a transaction request initiated by a client, and the first slave node is a slave node sending the transaction to the main node;
the master node generates a pre-submission block based on a block proposal and an endorsement signature of a first common node, wherein the first common node is used for representing a slave node which feeds back the endorsement signature to the master node in the block chain network;
the master node sends a submission request to a second slave node based on the confirmation information of the pre-submission block and a second consensus node, so that the second slave node submits the pre-submission block to the ledger based on the ledger synchronization mechanism, wherein the second consensus node is used for representing slave nodes which feed back the confirmation information to the master node in the block chain network, and the second slave nodes are all slave nodes in the block chain network.
In one possible implementation, the method for generating a block proposal corresponding to a transaction includes:
the main node configures transaction serial numbers for the transactions according to the receiving sequence and determines a transaction queue based on the transaction serial numbers;
and packaging the transaction queue and the signature of the main node to obtain a block proposal.
In one possible implementation, the generating, by the master node, a pre-submission block based on the block proposal and the endorsement signature of the first consensus node includes:
the main node broadcasts an endorsement request of a block proposal to a second slave node;
when the main node receives the endorsement signature of the first common knowledge node based on the endorsement request, the transaction queue, the main node signature and the endorsement signature of the first common knowledge node are packaged to obtain a pre-submission block, wherein the number of slave nodes in the first common knowledge node is determined by the configured endorsement parameters.
In one possible implementation, the method further includes:
when the main node does not receive endorsement signatures of the first recognition node based on the endorsement request, the main node regularly counts the number of the endorsement signatures within a preset endorsement time period;
and if the counted number of endorsement signatures in the preset endorsement time duration by the main node does not reach a first preset threshold, the main node abandons the block proposal.
In a possible implementation manner, the sending, by the master node, a submission request to the second slave node based on the pre-submission block and the confirmation information of the second consensus node, so that the second slave node submits the pre-submission block to the ledger based on the ledger synchronization mechanism includes:
the main node broadcasts a pre-submission block to a second slave node;
and after receiving confirmation information fed back by the second consensus node based on the pre-submission block, the master node sends a submission request to the second slave node, so that the second slave node submits the pre-submission block to the ledger based on the ledger synchronization mechanism, wherein the number of slave nodes in the second slave node is greater than a second preset threshold.
In one possible implementation, the method further comprises:
and when the main node does not receive the confirmation information fed back by the second common identification node based on the pre-submitted block, the main node returns to the step that the main node broadcasts the pre-submitted block to the second slave node.
In one possible implementation, the ledger-based synchronization mechanism includes: the system comprises a first account book synchronization mechanism and a second account book synchronization mechanism, wherein the first account book synchronization mechanism is used for representing that a slave node synchronization pre-submission block is randomly selected through a timing task, and the second account book synchronization mechanism is used for representing that the slave node synchronization pre-submission block is triggered through the heartbeat of a master node.
In one possible implementation, the method further includes:
when the master node is abnormal, the candidate master node sends a voting request to the second slave node;
the second slave node judges whether the request option number in the voting request is larger than the local option number or not to obtain a judgment result;
and the candidate main nodes carry out statistics on the judgment result to obtain a voting result.
In a possible implementation manner, after the candidate master node performs statistics on the determination result to obtain the voting result, the method further includes:
and if the candidate master node receives the heartbeat of the master node, the second slave node resets the election timer, wherein the duration of the election timer is longer than the time interval of sending the heartbeat by the master node.
In a possible implementation manner, after the candidate master node performs statistics on the determination result to obtain the voting result, the method further includes:
and if the candidate host node does not receive the heartbeat of the host node and the vote number in the voting result is greater than a third preset threshold value, taking the candidate host node as the host node and sending the heartbeat.
In one possible implementation, the height of the accounting block of the candidate master node is greater than the height of the accounting block of the slave node; or under the condition that the heights of the account blocks of the candidate main node and the slave node are the same, the expiration number of the latest pre-submitted block in the candidate main node is greater than that of the slave node; or, in the case that the heights of the accounting blocks of the candidate master node and the slave node are the same and the tenure number of the latest pre-committed block in the candidate master node is the same as the tenure number of the slave node, the height of the latest pre-committed block in the candidate master node is greater than the height of the latest pre-committed block in the slave node.
In a second aspect, an embodiment of the present invention provides a consensus device, including:
the block proposal generating module is used for receiving the transaction sent by the first slave node by the master node and generating a block proposal corresponding to the transaction, wherein the transaction is determined by a transaction request initiated by the client, and the first slave node is a slave node for sending the transaction to the master node;
the block generation module is used for generating a pre-submission block by the main node based on the block proposal and the endorsement signature of the first consensus node, wherein the first consensus node is used for representing a slave node which feeds back the endorsement signature to the main node in the block chain network;
and the block submitting module is used for the master node to send a submitting request to the second slave node based on the confirmation information of the pre-submitted block and the second consensus node so that the second slave node submits the pre-submitted block to the account book based on the account book synchronization mechanism, wherein the second consensus node is used for representing the slave nodes which feed back the determination information to the master node in the block chain network, and the second slave nodes are all slave nodes in the block chain network.
In a third aspect, an embodiment of the present invention provides a terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor executes the computer program to implement the steps of any one of the above-mentioned methods.
In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements the steps of any one of the above consensus methods.
The embodiment of the invention provides a consensus method, a consensus device, a terminal and a storage medium, wherein the consensus method comprises the following steps: the main node receives the transaction sent by the first slave node, generates a block proposal corresponding to the transaction, generates a pre-submission block based on the block proposal and an endorsement signature of the first consensus node, and sends a submission request to the second slave node based on the pre-submission block and the confirmation information of the second consensus node, so that the second slave node submits the pre-submission block to the account book based on an account book synchronization mechanism. The invention not only greatly improves the efficiency of transaction endorsement by processing endorsements in batches, but also accelerates the block submitting speed by submitting the request of the block in advance without needing to carry out submission confirmation after the next block is output, thereby reducing the delay of transaction chaining and improving the service stability.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this application, serve to provide a further understanding of the application and to enable other features, objects, and advantages of the application to be more apparent. The drawings and their description illustrate the embodiments of the invention and do not limit it. In the drawings:
fig. 1 is a flowchart illustrating an implementation of a consensus method according to an embodiment of the present invention;
fig. 2 is a flowchart illustrating an implementation of a method for interaction between a client and a node according to an embodiment of the present invention;
FIG. 3 is a block diagram of a block proposal according to an embodiment of the present invention;
fig. 4 is a flowchart of an implementation of a node endorsement method according to an embodiment of the present invention;
FIG. 5 is a block diagram of a pre-commit block according to an embodiment of the present invention;
fig. 6 is a flowchart illustrating an implementation of a method for submitting a block by a master node according to an embodiment of the present invention;
FIG. 7 is a flowchart illustrating an implementation of a consensus method according to another embodiment of the present invention;
fig. 8 is a flowchart illustrating an implementation of a method for selecting a master node according to an embodiment of the present invention;
fig. 9 is a flowchart of an implementation of a method for switching node types according to an embodiment of the present invention;
FIG. 10 is a schematic structural diagram of a consensus device according to an embodiment of the present invention;
fig. 11 is a schematic diagram of a terminal according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims, as well as in the drawings, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein.
It should be understood that, in various embodiments of the present invention, the sequence numbers of the processes do not mean the execution sequence, and the execution sequence of the processes should be determined by the functions and the internal logic of the processes, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
It should be understood that in the present application, "comprising" and "having" and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It should be understood that, in the present invention, "a plurality" means two or more. "and/or" is merely an association relationship describing an associated object, meaning that there may be three relationships, for example, and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "comprises A, B and C" and "comprises A, B, C" means that A, B, C all comprise, "comprises A, B or C" means that one of three A, B, C is comprised, "comprises A, B and/or C" means that any 1 or any 2 or 3 of three A, B, C are comprised.
It should be understood that in the present invention, "B corresponding to a", "a corresponds to B", or "B corresponds to a" means that B is associated with a, and B can be determined from a. Determining B from a does not mean determining B from a alone, but may also be determined from a and/or other information. And the matching of A and B means that the similarity of A and B is greater than or equal to a preset threshold value.
As used herein, "if" can be interpreted as "at … …" or "at … …" or "in response to a determination" or "in response to a detection", depending on context.
The technical solution of the present invention will be described in detail below with specific examples. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.
First, in order to make the technical solution of the present invention clear and easy to understand, the specialized vocabularies are explained as follows:
federation chain: a decentralized distributed blockchain network deployed in a particular network environment for only specific population members.
Crash fault tolerance: the method refers to that part of nodes in the block chain network are crashed, and the normal operation of the block chain is not influenced.
Byzantine fault tolerance: part of nodes in the block chain network are crashed or send error messages, and the normal operation of the block chain is not influenced.
And (3) workload proving: the blockchain node obtains the condition for generating a block by computing a time and resource consuming problem, typically a conditional hash. The consensus mechanism employs a cost-enhancing approach to prevent byzantine attacks.
The rights and interests prove that: using on-chain assets as a post-mortgage participant in block consensus also increases the cost of doing malicious but proves to be less computationally intensive and time consuming than the workload.
Further, in order to make the objects, technical solutions and advantages of the present invention more apparent, the following description is made by way of specific embodiments with reference to the accompanying drawings.
In one embodiment, as shown in fig. 1, there is provided a consensus method comprising the steps of:
step S101: the main node receives the transaction sent by the first slave node and generates a block proposal corresponding to the transaction.
The transaction is determined by a transaction request initiated by the client, and the first slave node is a slave node which sends the transaction to the master node.
The client side initiates a transaction request to the slave node in the block chain, and the slave node corresponding to the client side packages a transaction body and adds the signature of the client side after verifying the transaction request. Wherein, the client is a certain member, organization or light node. As shown in fig. 2, the client (organization 1) transmits a transaction request to the node (organization 1), and the client (organization 3) transmits a transaction request to the node (organization 3).
After the slave node forwards the transaction to the master node, the slave node waits for the request of the master node, and if the transaction is not processed successfully for a long time, the slave node can forward the transaction to the master node again or delete the transaction for retry by using the client.
And after the main node receives all transactions, the main node configures transaction serial numbers for the transactions according to the receiving sequence, determines a transaction queue based on the transaction serial numbers, and then encapsulates the transaction queue and the main node signature to obtain a block proposal.
Exemplarily, referring to fig. 3, the transactions sequentially received by the master node are transaction a, transaction B, and transaction C, and the transaction serial numbers are configured for transaction a, transaction B, and transaction C according to the receiving sequence, that is, transaction serial number 1 is configured for transaction a, transaction serial number 2 is configured for transaction B, and transaction serial number 3 is configured for transaction C, and transaction queues 1, 2, and 3 are formed after the transaction serial numbers are configured. And then the master node signs the transaction queue, and finally the transaction queue and the master node signs are packaged to obtain a block proposal.
Step S102: the master node generates a pre-commit block based on the block proposal and the endorsement signature of the first consensus node.
The first common identification node is used for representing a slave node which feeds back an endorsement signature to the master node in the block chain network.
And generating a pre-submission block through an endorsement stage, requiring the master node to broadcast an endorsement request submitted by the block to the second slave node, and when receiving an endorsement signature of the first consensus node based on the endorsement request, encapsulating the transaction queue, the master node signature and the endorsement signature of the first consensus node to obtain the pre-submission block.
Wherein, the number of the slave nodes in the first common node is determined by the configured endorsement parameter. The endorsement parameters include, but are not limited to, the required number of nodes for the endorsement stage, a node threshold, and the like, specifying that a participant organization must participate in endorsement.
Illustratively, in conjunction with fig. 3-5, the master node sends a chunk proposal to the slave node 1 and the slave node 2, and after the slave node 1 and the slave node 2 both feed back signatures to the master node, the slave node 1 signature and the slave node 2 signature are added to the chunk proposal shown in fig. 3, so as to form the pre-commit chunk shown in fig. 5.
When the master node does not receive the endorsement signature based on the endorsement request of the first common identification node, the master node regularly counts the number of the endorsement signatures within the preset endorsement time period, and if the counted number of the endorsement signatures within the preset endorsement time period of the master node does not reach a first preset threshold value, the master node gives up the block proposal. The preset endorsement duration and the first preset threshold may be set according to specific situations, and are not limited herein.
It should be noted that the first preset threshold is at least one, which refers to the number of nodes that need to feed back a signature, if the nodes that need to feed back a signature are one, that is, the master node, and if the nodes that need to feed back a signature are three, that is, the master node and the other two slave nodes.
The basic conditions for feeding back signatures (i.e. endorsements) from nodes are as follows: the slave node verifies the hash of the previous block of the block proposal to ensure that the new block extends from the current newest block, and prevents the master node from expanding based on the old block and generating chain branching. The slave node needs to verify that the current block proposal was generated and sent by the master node and therefore needs to verify the signature of the party organisation on behalf of the master node. If the slave node does not synchronize the latest block, endorsement (i.e. signature) cannot be made. In addition, the slave node is also supported to check or audit the transaction in the block proposal and manually intervene to audit.
Step S103: the master node sends a submission request to a second slave node based on the confirmation information of the pre-submission block and a second consensus node, so that the second slave node submits the pre-submission block to the ledger based on the ledger synchronization mechanism, wherein the second consensus node is used for representing slave nodes which feed back the confirmation information to the master node in the block chain network, and the second slave nodes are all slave nodes in the block chain network.
The method comprises the steps that a master node is required to broadcast a pre-submission block to a second slave node, when the master node receives confirmation information fed back by a second consensus node based on the pre-submission block, a submission request is sent to the second slave node, so that the second slave node submits the pre-submission block to an account book based on an account book synchronization mechanism, wherein the number of slave nodes in the second slave node is larger than a second preset threshold value.
Specifically, with reference to fig. 6, after the master node generates the pre-submission block, the pre-submission block is broadcast to other slave nodes (i.e., second slave nodes), and each slave node checks the request of the master node and then makes a response indicating whether the master node can submit the request according to the local account book and the role authority. The communication process of the pre-submission stage and the endorsement stage is roughly the same, and the difference is that the pre-submission stage needs confirmation information of nodes meeting a second preset threshold, for example, more than 50% of the nodes are confirmed. And a plurality of dispatching mechanisms are arranged, so that the safety of block chains in the time zone switched by the main node is ensured, and the condition that account book blocks of all nodes are inconsistent is prevented.
And the slave node verifies the signature of the master node and sends a response for confirming the submission after the hash of the previous block, and the slave node indicates that the condition for submitting the block is available. After receiving the pre-submission confirmation of more than 50% of the nodes, the main node immediately submits the blocks and broadcasts submission requests to all the slave nodes, and the slave nodes submit the blocks after verifying the requests.
When a node persists a block into the ledger, the block on the node at that time cannot be deleted or overwritten. An explicit commit request may make the block unnecessary to wait for the next block out by the master node so that the block can be committed quickly.
In addition, when the main node does not receive the confirmation information fed back by the second common identification node based on the pre-submitted block, the main node returns to the step that the main node broadcasts the pre-submitted block to the second slave node.
Specifically, if there are many nodes rejecting the acknowledgement at this stage, it indicates that the blocks of these nodes are not yet completed synchronously, and the blocks will eventually be committed. The commit phase has no timeout failure mechanism and the master node will retry the pre-commit phase indefinitely.
If more than half of the nodes do not respond, the network of the nodes is not passed or is in a breakdown state, and the fault tolerance quantity of the nodes exceeds the common fault tolerance capability at the moment, so that the block chain is temporarily in an unavailable state.
Wherein, based on account book synchronization mechanism includes: the system comprises a first account book synchronization mechanism and a second account book synchronization mechanism, wherein the first account book synchronization mechanism is used for representing that a slave node synchronization pre-submission block is randomly selected through a timing task, and the second account book synchronization mechanism is used for representing that the slave node synchronization pre-submission block is triggered through the heartbeat of a master node.
The ledger synchronization mechanism is independent of the various stages shown in figure 7. The node newly joining the blockchain network or the restarted slave node can not update the local accounting block because the consensus of the above stages is missed. The account blocks of all nodes are the same and can not be tampered, so that nodes behind the account can request the account blocks from any node in the network through an account synchronization mechanism, the communication pressure of the main node is greatly reduced, the block-out frequency of the main node can be accelerated, and the uplink speed is increased.
The account book synchronization mechanism is relatively independent, and can be flexibly realized according to scene requirements without worrying about the safety and activity of the consensus method. The node synchronization account block can be randomly selected through the timing task, and the heartbeat of the main node can be used for triggering the synchronization mechanism of the slave node, so that the node behind the account can quickly update the account and participate in the consensus of a new round of blocks.
In an embodiment, the present application further provides a master node selection mechanism, and specifically, when a master node is abnormal, a candidate master node sends a voting request to a second slave node, the second slave node determines whether a request option number in the voting request is greater than a local option number, to obtain a determination result, and then the candidate master node performs statistics on the determination result, to obtain a voting result.
If the candidate master node receives the heartbeat of the master node, the second slave node resets an election timer, wherein the duration of the election timer is longer than the time interval of the heartbeat sent by the master node; and if the candidate host node does not receive the heartbeat of the host node and the vote number in the voting result is greater than a third preset threshold value, taking the candidate host node as the host node and sending the heartbeat.
Specifically, the selection mechanism of the master node provides activity for the consensus scheme, so that the block chain network does not block a normal block outlet process within the fault tolerance capability. The main node plays a main role in the consensus advancing process, and the selection mechanism of the main node plays a role in reselecting a main node under the scenes of main node crash or network abnormity and the like.
Each node internally needs to maintain a monotonically increasing tenure number. The master node has a unique option number in the optional period, and the option number is increased after the master node is switched. Each slave node maintains an election timer, and after the timer is finished, the slave node initiates a new host node election in an appointed period, so that the master node needs to send heartbeat regularly to reset the timer of the slave node, and the master control of the master node is maintained.
If the slave node does not receive the heartbeat of the master node for a long time, the timer of the slave node is ended, then a round of election is initiated and becomes a master node candidate (namely, a candidate master node), and at the moment, the option number of the candidate node is added with 1 on the original basis, and meanwhile, a vote agreeing ticket is cast for election of the candidate node.
After receiving the election voting request, each slave node firstly judges whether the option number is larger than the local option number and whether the candidate node meets the election limit. The determination of the slave node for the option number ensures that the node only throws election consent tickets once in an option number, again to prevent having only one master node in the same option period.
The method and the device for block submission provide safety for the scheme, and guarantee that blocks received by nodes above a third threshold are successfully submitted by limiting nodes which do not meet requirements to be elected as master nodes. The node stores all the pre-submitted blocks which are not submitted into the account and is bound with an optional number, the optional number is given to the pre-submitted block by the main node and is informed to all the nodes through the broadcast of the pre-submitted block.
And setting the third threshold value as 50%, wherein the candidate master nodes can be successfully elected only by obtaining election voting confirmation of more than 50% of nodes, and the mechanism ensures that only one master node exists in each optional period, so that the network is prevented from generating brain cracks to cause block chains to be forked.
The time for resetting the election timer each time needs to be randomly generated, and the situation that a plurality of nodes initiate elections at the same time to enable votes to be divided is avoided. Vote segmentation, that is, different nodes in the network cast election votes to different candidates, so that the vote quantity of all the candidates does not meet the requirement of more than 50%, and thus the host node at the current date cannot be elected, and the host node may be elected only through multiple rounds of elections. Therefore, the random election timer time can greatly improve the election success rate.
An important configuration of the consensus scheme is: the election timer time needs to be much longer than the interval between the master node sending heartbeats. This limitation allows no slave node to actively initiate elections in the case of normal master node operation. The election timer time may be configured to have a range with a lower limit that is much greater than the heartbeat interval time. For example, if the heartbeat interval time is n milliseconds in consideration of network delay, the election timer time may be configured to range from 5n to 10n milliseconds.
Wherein the height of the accounting block of the candidate main node is greater than that of the slave node; or under the condition that the heights of the account blocks of the candidate main node and the slave node are the same, the expiration number of the latest pre-submitted block in the candidate main node is greater than that of the slave node; or, in the case that the heights of the accounting blocks of the candidate master node and the slave node are the same and the tenure number of the latest pre-committed block in the candidate master node is the same as the tenure number of the slave node, the height of the latest pre-committed block in the candidate master node is greater than the height of the latest pre-committed block in the slave node.
It should be noted that, in the master node selection mechanism, the candidate master node needs to satisfy at least one of the first and second bars, or at least one of the first and third bars.
And setting the third threshold value as 50%, the candidate master node periodically counts the voting results after broadcasting the voting request. If more than 50% of nodes agree, the nodes successfully select the master node and start to broadcast the heartbeat regularly. If more than 50% of the nodes refuse, the node changes back to the slave node and resets the election timer.
In addition to the above two explicit successes or failures, if the candidate does not receive enough voting response within a certain time, the voting request will be broadcasted again for voting retry, and the retry mechanism will continue until the candidate master node receives the heartbeat of the master node or receives enough voting response number to judge the voting result.
Therefore, if one node a and other nodes generate network partitions due to network problem non-intercommunication, the node a cannot receive enough voting response after entering the candidate state, the expiration number of the node a is not changed and continuously broadcasts voting requests, and the node a can successfully receive heartbeats and becomes a slave node after the network is restored.
The heartbeat request in a broad sense includes all requests broadcast by the master node to the slave nodes, including endorsement requests, pre-commit requests, etc. at various stages, which are received by the slave nodes and require resetting the election timer and updating the option number to the latest. While the heartbeat in the narrow sense is a request from the master node with no other effect, and the purpose is only to reset the slave node election timer.
As shown in fig. 9, the heartbeat request broadcast by the master node (Leader) includes the current task number of the master node, and the task number is used as a basis for each node to determine whether the master node is changed. Both the slave node (Follower) and the Candidate master node (candiddate) accept heartbeats with an option number equal to or greater than the local option number, wherein the Candidate master node receiving a heartbeat with the same local option number indicates that the node fails in the option of the option and the other node has successfully elected the master node of the option. The master node only approves the heartbeat with the option number larger than the local option number, because two master nodes cannot appear in the same option, and the heartbeat with the larger option number received by the master node indicates that the node becomes the expired master node, thereby changing back to the slave node.
The embodiment of the invention provides a consensus method, which comprises the following steps: the main node receives the transaction sent by the first slave node, generates a block proposal corresponding to the transaction, generates a pre-submission block based on the block proposal and an endorsement signature of the first consensus node, and sends a submission request to the second slave node based on the pre-submission block and the confirmation information of the second consensus node, so that the second slave node submits the pre-submission block to the account book based on an account book synchronization mechanism. The invention not only greatly improves the efficiency of transaction endorsement by processing endorsements in batches, but also accelerates the block submitting speed by submitting the request of the block in advance without needing to carry out submission confirmation after the next block is output, thereby reducing the delay of transaction chaining and improving the service stability.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.
The following are embodiments of the apparatus of the invention, reference being made to the corresponding method embodiments described above for details which are not described in detail therein.
Fig. 10 is a schematic structural diagram of a consensus device provided in an embodiment of the present invention, and for convenience of description, only the parts related to the embodiment of the present invention are shown, and the consensus device includes a block proposal generation module 1001, a block generation module 1002, and a block submission module 1003, which are specifically as follows:
a block proposal generating module 1001, configured to receive, by a master node, a transaction sent by a first slave node, and generate a block proposal corresponding to the transaction, where the transaction is determined by a transaction request initiated by a client, and the first slave node is a slave node that sends the transaction to the master node;
a block generating module 1002, configured to generate, by a master node, a pre-submitted block based on a block proposal and an endorsement signature of a first common node, where the first common node is used to represent a slave node in a block chain network, the slave node feeding back the endorsement signature to the master node;
the block submitting module 1003 is configured to send, by the master node, a submission request to the second slave node based on the confirmation information of the pre-submission block and the second consensus node, so that the second slave node submits the pre-submission block to the ledger based on the ledger synchronization mechanism, where the second consensus node is used to characterize a slave node in the blockchain network that feeds back the determination information to the master node, and the second slave node is all slave nodes in the blockchain network.
In one possible implementation, the block proposal generating module 1001 is further configured to configure a transaction sequence number for the transaction according to the receiving sequence, and determine a transaction queue based on the transaction sequence number; and packaging the transaction queue and the signature of the main node to obtain a block proposal.
In a possible implementation manner, the block generation module 1002 is further configured to broadcast, by the master node, an endorsement request of the block proposal to the second slave node; when the main node receives the endorsement signature of the first common knowledge node based on the endorsement request, the transaction queue, the main node signature and the endorsement signature of the first common knowledge node are packaged to obtain a pre-submission block, wherein the number of slave nodes in the first common knowledge node is determined by the configured endorsement parameters.
In a possible implementation manner, the device further comprises a first judging module, wherein the first judging module is used for regularly counting the number of endorsement signatures within a preset endorsement time period when the master node does not receive the endorsement signature based on the endorsement request of the first common identification node; and if the counted number of endorsement signatures in the preset endorsement duration by the master node does not reach a first preset threshold, the master node abandons the block proposal.
In one possible implementation, the block submitting module 1003 further includes the master node broadcasting the pre-submitted block to the second slave node; and after receiving confirmation information fed back by the second consensus node based on the pre-submission block, the master node sends a submission request to the second slave node, so that the second slave node submits the pre-submission block to the ledger based on the ledger synchronization mechanism, wherein the number of slave nodes in the second slave node is greater than a second preset threshold.
In a possible implementation manner, the apparatus further includes a second determining module, where the second determining module is configured to return to the master node to broadcast the pre-commit block to the second slave node when the master node does not receive the confirmation information fed back by the second consensus node based on the pre-commit block.
In one possible implementation, the ledger-based synchronization mechanism includes: the system comprises a first account book synchronization mechanism and a second account book synchronization mechanism, wherein the first account book synchronization mechanism is used for representing that a slave node synchronization pre-submission block is randomly selected through a timing task, and the second account book synchronization mechanism is used for representing that the slave node synchronization pre-submission block is triggered through the heartbeat of a master node.
In a possible implementation manner, the device further comprises a third judging module, where the third judging module is used to send a voting request to the second slave node by the candidate master node when the master node is abnormal; the second slave node judges whether the request option number in the voting request is larger than the local option number or not to obtain a judgment result; and the candidate main nodes carry out statistics on the judgment result to obtain a voting result.
In a possible implementation manner, the third determining module further includes a fourth determining module, after the third determining module, the fourth determining module is configured to reset the election timer by the second slave node if the candidate master node receives the heartbeat of the master node, where a duration of the election timer is greater than a time interval of sending the heartbeat by the master node.
In a possible implementation manner, the fourth determining module further includes a fifth determining module, after the fourth determining module, the fifth determining module is configured to, if the candidate host node does not receive the heartbeat of the host node, and the number of votes in the voting result is greater than a third preset threshold, use the candidate host node as the host node and send the heartbeat.
In one possible implementation, the height of the accounting block of the candidate master node is greater than the height of the accounting block of the slave node; or, under the condition that the heights of the account blocks of the candidate main node and the slave node are the same, the expiration number of the latest pre-submitted block in the candidate main node is larger than that of the slave node; or, in the case that the heights of the accounting blocks of the candidate master node and the slave node are the same and the tenure number of the latest pre-committed block in the candidate master node is the same as the tenure number of the slave node, the height of the latest pre-committed block in the candidate master node is greater than the height of the latest pre-committed block in the slave node.
Fig. 11 is a schematic diagram of a terminal according to an embodiment of the present invention. As shown in fig. 11, the terminal 11 of this embodiment includes: a processor 1101, a memory 1102, and a computer program 1103 stored in the memory 1102 and operable on the processor 1101. The processor 1101, when executing the computer program 1103, implements the steps in the various consensus method embodiments described above, such as the steps 101 to 103 shown in fig. 1. Alternatively, the processor 1101, when executing the computer program 1103, implements the functions of the modules/units in the above-described respective embodiments of the consensus device, such as the modules/units 1001 to 1003 shown in fig. 10.
The present invention also provides a readable storage medium, in which a computer program is stored, and the computer program is used for implementing the consensus method provided by the various embodiments described above when being executed by a processor.
The readable storage medium may be a computer storage medium or a communication medium. Communication media includes any medium that facilitates transfer of a computer program from one place to another. Computer storage media may be any available media that can be accessed by a general purpose or special purpose computer. For example, a readable storage medium is coupled to the processor such that the processor can read information from, and write information to, the readable storage medium. Of course, the readable storage medium may also be an integral part of the processor. The processor and the readable storage medium may reside in an Application Specific Integrated Circuits (ASIC). Additionally, the ASIC may reside in user equipment. Of course, the processor and the readable storage medium may also reside as discrete components in a communication device. The readable storage medium may be read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and the like.
The present invention also provides a program product comprising execution instructions stored in a readable storage medium. The executable instructions may be read from a readable storage medium by at least one processor of the device, and execution of the executable instructions by the at least one processor causes the device to implement the consensus methods provided by the various embodiments described above.
In the above embodiments of the apparatus, it should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose processors, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present invention may be embodied directly in a hardware processor, or in a combination of the hardware and software modules within the processor.
The above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present invention, and are intended to be included within the scope of the present invention.
Claims (14)
1. A consensus method, comprising:
the method comprises the steps that a main node receives a transaction sent by a first slave node, and generates a block proposal corresponding to the transaction, wherein the transaction is determined by a transaction request initiated by a client, and the first slave node is a slave node sending the transaction to the main node;
the main node generates a pre-submission block based on the block proposal and an endorsement signature of a first consensus node, wherein the first consensus node is used for representing a slave node in the block chain network, which feeds back the endorsement signature to the main node;
the master node sends a submission request to a second slave node based on the confirmation information of the pre-submission block and a second consensus node, so that the second slave node submits the pre-submission block to an account based on an account synchronization mechanism, wherein the second consensus node is used for representing slave nodes in the blockchain network which feed back the confirmation information to the master node, and the second slave nodes are all slave nodes in the blockchain network.
2. The consensus method of claim 1, wherein the master node receiving a transaction sent by a first slave node and generating a block proposal corresponding to the transaction comprises:
the main node configures transaction serial numbers for the transactions according to a receiving sequence and determines a transaction queue based on the transaction serial numbers;
and encapsulating the transaction queue and the signature of the main node to obtain the block proposal.
3. The consensus method of claim 1, wherein the master node generating a pre-commit block based on the block proposal and an endorsement signature of the first consensus node comprises:
the master node broadcasts an endorsement request of the block proposal to the second slave node;
when the main node receives the endorsement signature of the first common knowledge node based on the endorsement request, the transaction queue, the main node signature and the endorsement signature of the first common knowledge node are packaged to obtain the pre-submission block, wherein the number of the slave nodes in the first common knowledge node is determined by the configured endorsement parameters.
4. The consensus method of claim 3, further comprising:
when the main node does not receive the endorsement signature based on the endorsement request of the first common identification node, the main node regularly counts the number of endorsement signatures within a preset endorsement time period;
and if the counted number of endorsement signatures in the preset endorsement duration by the main node does not reach a first preset threshold value, the main node abandons the block proposal.
5. The consensus method as claimed in claim 1, wherein the master node sending a commit request to a second slave node based on the pre-commit block and acknowledgement information of the second consensus node to cause the second slave node to commit the pre-commit block to the ledger based on an ledger synchronization mechanism, comprising:
the master node broadcasting the pre-commit block to the second slave node;
after receiving confirmation information fed back by the second consensus node based on the pre-submission block, the master node sends a submission request to the second slave node, so that the second slave node submits the pre-submission block to an account book based on an account book synchronization mechanism, wherein the number of slave nodes in the second slave node is greater than a second preset threshold.
6. The consensus method of claim 5, further comprising:
and when the main node does not receive the confirmation information fed back by the second common identification node based on the pre-submitted block, the main node returns to the step that the main node broadcasts the pre-submitted block to the second slave node.
7. The consensus method of any one of claims 1-6, wherein the ledger-based synchronization mechanism comprises: the system comprises a first account book synchronization mechanism and a second account book synchronization mechanism, wherein the first account book synchronization mechanism is used for representing that a slave node is randomly selected to synchronize the pre-submission block through a timing task, and the second account book synchronization mechanism is used for representing that the slave node is triggered to synchronize the pre-submission block through the heartbeat of the master node.
8. The consensus method of claim 1, further comprising:
when the master node is abnormal, the candidate master node sends a voting request to the second slave node;
the second slave node judges whether the request option number in the voting request is larger than the local option number or not to obtain a judgment result;
and the candidate master node counts the judgment result to obtain a voting result.
9. The consensus method as claimed in claim 8, wherein the candidate master node performs statistics on the determination results to obtain voting results, further comprising:
and if the candidate master node receives the heartbeat of the master node, resetting an election timer by the second slave node, wherein the duration of the election timer is longer than the time interval of sending the heartbeat by the master node.
10. The consensus method as claimed in claim 8, wherein the candidate master node performs statistics on the determination results to obtain voting results, further comprising:
and if the candidate main node does not receive the heartbeat of the main node and the vote number in the voting result is greater than a third preset threshold value, taking the candidate main node as the main node and sending the heartbeat.
11. A consensus method as claimed in any one of claims 8-10 wherein the master node candidate has a greater accounting block height than the slave node; or, under the condition that the heights of the account blocks of the candidate main node and the slave node are the same, the expiration number of the latest pre-submitted block in the candidate main node is larger than that of the slave node; or, in the case that the heights of the accounting blocks of the candidate master node and the slave node are the same and the tenure number of the latest pre-committed block in the candidate master node is the same as the tenure number of the slave node, the height of the latest pre-committed block in the candidate master node is greater than the height of the latest pre-committed block in the slave node.
12. A consensus device, comprising:
the system comprises a block proposal generating module, a main node and a plurality of slave nodes, wherein the block proposal generating module is used for receiving a transaction sent by a first slave node by the main node and generating a block proposal corresponding to the transaction, the transaction is determined by a transaction request initiated by a client, and the first slave node is a slave node sending the transaction to the main node;
a block generation module, configured to generate, by the master node, a pre-submission block based on the block proposal and an endorsement signature of a first consensus node, where the first consensus node is used to characterize a slave node in the block chain network that feeds back the endorsement signature to the master node;
and the block submitting module is used for the master node sending a submitting request to a second slave node based on the confirmation information of the pre-submitted block and a second consensus node so as to enable the second slave node to submit the pre-submitted block to an account book based on an account book synchronization mechanism, wherein the second consensus node is used for representing slave nodes which feed back the confirmation information to the master node in the blockchain network, and the second slave nodes are all slave nodes in the blockchain network.
13. A terminal comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the steps of the consensus method as claimed in one of claims 1 to 11 when executing the computer program.
14. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the consensus method as claimed in one of claims 1 to 11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211280956.2A CN115622713A (en) | 2022-10-19 | 2022-10-19 | Consensus method, device, terminal and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211280956.2A CN115622713A (en) | 2022-10-19 | 2022-10-19 | Consensus method, device, terminal and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115622713A true CN115622713A (en) | 2023-01-17 |
Family
ID=84865351
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211280956.2A Pending CN115622713A (en) | 2022-10-19 | 2022-10-19 | Consensus method, device, terminal and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115622713A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116614311A (en) * | 2023-07-18 | 2023-08-18 | 中移(苏州)软件技术有限公司 | Mirror image signature method, device, service node, terminal and readable storage medium |
| CN116723200A (en) * | 2023-08-11 | 2023-09-08 | 杭州趣链科技有限公司 | Cluster changing method and device, electronic equipment and computer readable storage medium |
-
2022
- 2022-10-19 CN CN202211280956.2A patent/CN115622713A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116614311A (en) * | 2023-07-18 | 2023-08-18 | 中移(苏州)软件技术有限公司 | Mirror image signature method, device, service node, terminal and readable storage medium |
| CN116614311B (en) * | 2023-07-18 | 2023-11-03 | 中移(苏州)软件技术有限公司 | Mirror image signature method, device, service node, terminal and readable storage medium |
| CN116723200A (en) * | 2023-08-11 | 2023-09-08 | 杭州趣链科技有限公司 | Cluster changing method and device, electronic equipment and computer readable storage medium |
| CN116723200B (en) * | 2023-08-11 | 2023-11-10 | 武汉趣链数字科技有限公司 | Cluster changing method and device, electronic equipment and computer readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN115622713A (en) | Consensus method, device, terminal and storage medium | |
| US11775377B2 (en) | Distributed system, message processing method, nodes, client, and storage medium | |
| US10833919B2 (en) | Node device operation method, work status switching apparatus, node device, and medium | |
| EP3580913B1 (en) | Consensus system downtime recovery | |
| CN114422155B (en) | Proposal consensus execution method, block chain system, device and storage medium | |
| CN113347164A (en) | Block chain-based distributed consensus system, method, device and storage medium | |
| CN113965578B (en) | Election method, device, equipment and storage medium of master node in cluster | |
| CN109194493B (en) | Information management system, method and device | |
| CN112492016A (en) | Cross-process extensible consensus method and system | |
| CN113760468A (en) | Distributed election method, device, system and medium | |
| CN111555858B (en) | Practical Byzantine fault-tolerant consensus method based on block chain type storage | |
| CN110417833B (en) | Data processing method and device based on block chain and storage medium | |
| CN114936253A (en) | Block chain consensus method and device, electronic equipment and storage medium | |
| Abraham et al. | Optimal good-case latency for rotating leader synchronous bft | |
| Bazzi et al. | Clairvoyant state machine replication | |
| CN110941622A (en) | Data processing method and device | |
| CN111064813B (en) | Method and device for synchronizing processing messages during block chain consensus processing | |
| CN116232893A (en) | Consensus method and device of distributed system, electronic equipment and storage medium | |
| CN112258184B (en) | Method, apparatus, electronic device and readable storage medium for freezing blockchain network | |
| CN111818152B (en) | Leader election consensus method based on distributed network | |
| CN111190754B (en) | Block chain event notification method and block chain system | |
| CN112511312A (en) | Assembled consensus method and system | |
| CN114095209A (en) | Weight-incentive-based alliance chain consensus method and system for main node election | |
| CN113609229A (en) | Rapid log replication method and device in Fabric Block chain | |
| CN110555774A (en) | Distributed consensus mechanism with arbitration |
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 |