A Byzantine Fault Tolerant Consensus Method Applied to Blockchain

Abstract

The present invention discloses a Byzantine fault-tolerant consensus method applied to blockchain, comprising: blocks are generated before the consensus process, and transactions are distributed to corresponding nodes based on signatures; the nominated node for the current round of consensus is calculated based on the block height, round, and the number of blocks that each node can continuously produce, and the node is responsible for proposing a block to join the blockchain; the nodes vote on the proposals in turn, and when a proposal fails to be submitted, the protocol will enter the next round, and the new nominated node will propose a new block for the height; the successful submission of a block requires two stages of voting, namely pre-voting and pre-submitting voting; a locking and unlocking mechanism is used to avoid bifurcation of written blocks; a gossip mechanism ensures that the consensus nodes reach a consistent state as soon as possible. Therefore, the present invention can achieve a random and uniform transaction distribution process with load balancing; node election is conducive to decentralization, prevents single points of failure, and enhances robustness; and multi-stage voting ensures system security.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular relates to a Byzantine fault-tolerant consensus method applied to blockchain. Background Art

[0002] Blockchain technology is a distributed database technology that provides a shared ledger and database. It boasts prominent features such as decentralization, data immutability, full traceability, collective maintenance, and robustness. By combining encryption algorithms, distributed data storage, peer-to-peer network transmission, and consensus mechanisms, blockchain technology has created a decentralized, transparent, autonomous, trustworthy, and tamper-proof value exchange platform with broad application prospects.

[0003] In blockchain systems, consensus algorithms are used to solve the consistency problem of distributed ledgers. Currently, the commonly used consensus algorithms in blockchains include PoW (Proof of Work), PoS (Proof of Stake), DPOS (Delegated Proof of Stake), and PBFT (Practical Byzantine Fault Tolerance). Among them, the PBFT consensus algorithm is a Byzantine fault-tolerant algorithm that can tolerate malicious nodes. The algorithm was proposed by Miguel Castro and Barbara Liskov in 1999. It reduces the algorithm complexity from exponential to polynomial, solving the problem of low efficiency of the original Byzantine fault-tolerant algorithm. The time complexity of the algorithm is O(n 2 ), which makes it possible to solve the Byzantine fault tolerance problem in actual system applications.

[0004] However, the traditional PBFT algorithm uses View Change to trigger master node rotation to handle various voting timeouts and node malicious scenarios. This process is cumbersome, complex to implement, and time-consuming. Moreover, if the master node goes down or behaves maliciously, the PBFT algorithm replaces the master node through a random sequential election. As a result, the next master node is likely to be a Byzantine node, resulting in a waste of resources. Summary of the Invention

[0005] Based on the above background and the problems existing in the prior art, the present invention proposes a Byzantine fault-tolerant consensus method for blockchain, which provides a signature-based transaction distribution method to ensure that the transaction distribution process is random and uniform, rather than being sent centrally to a specific node; a nomination node selection method based on block height and round, in which the appropriate nomination node is replaced in each round to ensure system security; a locking and unlocking mechanism to avoid forks; and a gossip mechanism to enable nodes across the entire network to reach consensus faster.

[0006] A technical approach to the Byzantine fault-tolerant consensus method applied to blockchain is as follows:

[0007] After obtaining the transaction information, the transaction queue of the corresponding consensus node will be distributed according to the transaction signature, and the consensus node will produce blocks according to the block production strategy;

[0008] The consensus process for adding each block to the blockchain is divided into five stages: new height stage, proposal stage, pre-voting stage, pre-commit stage, and commit stage. After the pre-commit vote is passed, the block is written to the blockchain, and a locking and unlocking mechanism is used to avoid possible forks during the block writing process.

[0009] In the proposal phase, a node is elected from the consensus nodes as the nominating node. The nominating node initiates a proposal for the current block to be added to the blockchain and broadcasts the proposal to other consensus nodes.

[0010] In the three stages of pre-voting, pre-submission, and submission, each consensus node will vote on the proposal separately. If more than 2 / 3 of the consensus nodes vote in favor of the proposal in a certain stage, it will enter the corresponding next stage;

[0011] When a timeout code or a valid proposal is received during the proposal phase and more than 2 / 3 of the nodes vote in the pre-voting, pre-submission, and submission phases, the state of the consensus node will change. The gossip mechanism will be used to enable all consensus nodes in the entire network to reach a consistent state as quickly as possible.

[0012] The signature-based transaction splitting method has the following specific process: convert the last digit of the transaction signature into an integer; perform a modulo operation on the obtained integer with the number of consensus nodes to obtain the remainder; the obtained remainder is the subscript of the consensus node object that needs to be distributed for the current transaction.

[0013] The specific steps to elect a node from the consensus nodes as a nominating node are as follows:

[0014] (1) Calculate the height offset hf: add one to the current height and divide it by the number of blocks that each node can withdraw. The integer part of the result is the height offset.

[0015] (2) Calculate the round offset rf: The current round is modulo the total number of consensus nodes, and the result is the round offset;

[0016] (3) Calculate the nominated node index pi: Sum the height offset hf and round offset rf obtained in (1) and (2), and take the modulo the total number of consensus nodes. The result is the nominated node index.

[0017] The locking and unlocking mechanism includes the following:

[0018] In any round, a block with more than 2 / 3 of the pre-votes is called a polka, and a block with more than 2 / 3 of the empty pre-votes is called a nil-polka.

[0019] Locking mechanism: Each consensus node records and maintains the blocks received from Polka in each round in its own consensus state, that is, the proposals it pre-submitted with voting signatures, and locks them in the blocks described by the proposals. If the current node is locked on a certain block, in higher rounds, the node can only pre-vote for the block as a non-nominated node, and can only initiate proposals for the block as a nominated node.

[0020] Unlocking mechanism: When a consensus node receives a polka or nil-polka proposal with a higher block round than the one it has locked, it can unlock itself and pre-submit a voting signature for the proposal with the higher round.

[0021] The gossip mechanism described above provides three ways of data interaction between nodes:

[0022] (1) Through the Push method, the first consensus node that initiates information exchange randomly selects the second consensus node to contact and sends its own information to it. After receiving the information, the second consensus node updates the data that is newer than its own. Generally, the node with the new information will be the initiating node;

[0023] (2) Through the Pull method, the first consensus node that initiates information exchange randomly contacts the second consensus node and obtains information from the other party; the consensus node without new information will serve as the initiating node;

[0024] (3) Through the Push and Pull methods, the first consensus node that initiates information exchange sends information to the selected second consensus node, and at the same time obtains data from the other party to update its own local data.

[0025] The node voting is characterized in that the node voting data storage structure includes:

[0026] (1) Node voting types include proposal, pre-voting, pre-submission, and submission. They are used to identify the stages of voting, namely proposal stage, pre-voting stage, pre-submission stage, and submission stage.

[0027] (2) The block height of the node vote, which is used to identify the block height in the node vote proposal;

[0028] (3) The node’s current voting round, which is used to identify the round of the block in the node’s voting proposal;

[0029] (4) The block hash of the node vote, which is used to ensure that the block in the node vote proposal is unique;

[0030] (5) Voting node subscript, used to identify the voting node;

[0031] (6) The signature of the voting node is used to ensure the uniqueness of the vote.

[0032] During the pre-voting phase, consensus nodes continuously monitor for new proposals for blocks to be added to the blockchain. Upon receiving the proposal, each consensus node verifies the authenticity, reliability, and legitimacy of the proposal and the nominating node. After verification, the proposal is pre-voted and signed, and broadcast to the network. If a node does not receive a valid proposal within the specified proposal time, its pre-vote for the proposal is empty. When more than 2 / 3 of the consensus nodes approve the proposal, the pre-voting phase is completed and the pre-commitment phase begins.

[0033] During the pre-commit phase, each consensus node continuously receives pre-votes from the network. If a node collects more than 2 / 3 of the pre-votes from the total number of consensus nodes, it broadcasts a pre-commit vote for the proposal, and the current node locks on the proposal while releasing the previously locked proposal. A node can only lock on one proposal. If a node receives more than 2 / 3 of the empty block pre-votes from the total number of consensus nodes, the current node will release all previously locked proposals. If a node does not collect more than 2 / 3 of the pre-votes from any type of consensus nodes, it will not lock on any proposal. In the later stage of the pre-commit phase, if a node collects more than 2 / 3 of the pre-commit votes from the total number of consensus nodes, then the node enters the commit phase, otherwise it enters the next round of proposal phase.

[0034] During the pre-commit phase, each consensus node continuously receives pre-votes from the network. The consensus node will sign the blocks proposed through the pre-vote and broadcast the pre-commit vote. In the late pre-commit phase, if the node collects more than 2 / 3 of the pre-commit votes from the total number of consensus nodes, then the node enters the commit phase, otherwise it enters the next round of proposal phase.

[0035] During the submission phase, each consensus node continuously receives pre-submission votes from the network. If a node collects more than 2 / 3 of the pre-submission votes from the total number of consensus nodes, it broadcasts a submission vote for the proposal. The node continuously collects submission votes from the network. If it collects more than 2 / 3 of the submission votes from the total number of consensus nodes, it sets the submission time to the current time and enters the new height phase, starting a new round.

[0036] At any stage of the entire consensus process, once a node receives pre-commit votes from more than 2 / 3 of the total number of consensus nodes, the node will immediately enter the commit phase.

[0037] The present invention has at least the following beneficial effects:

[0038] 1. The signature-based transaction distribution method ensures that the transaction distribution process is random and uniform, rather than being concentrated on a specific node, achieving load balancing and improving system performance;

[0039] 2. The election of nominating nodes is conducive to decentralization, preventing single points of failure and enhancing the robustness of the system;

[0040] 3. The three-stage voting process of pre-voting, pre-submission, and submission makes the system more secure compared to single-stage voting;

[0041] 4. The locking and unlocking mechanism prevents forks from occurring when blocks are added to the blockchain;

[0042] 5. The gossip mechanism enables nodes in the entire network to reach a consistent state more quickly. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a diagram of the block production process based on height and rounds.

[0044] Figure 2 This is a five-stage consensus flow chart.

[0045] Figure 3 Schematic diagram for signature-based transaction distribution. DETAILED DESCRIPTION

[0046] In order to clearly explain the present invention and make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention, so that those skilled in the art can implement them according to the description. The following is a detailed description of the technology of the present invention in conjunction with the drawings and specific embodiments.

[0047] like Figure 1 As shown, the block generation process based on height and round generally has five steps that are executed in a continuous cycle:

[0048] Step 1: Enter the new height stage, wait for a while, and then enter the proposal stage.

[0049] Step 2: Proposal phase: elect a nominating node, which then submits a proposal for the current block to be added to the blockchain, entering the pre-voting phase.

[0050] Step 3: Pre-voting phase: Nodes pre-vote on the received proposals. When 2 / 3 of the pre-votes are achieved, the pre-commit phase begins.

[0051] Step 4: Pre-submission stage, pre-submission voting is carried out. When 2 / 3 of the votes are reached, the submission stage begins. If the votes are not reached, the proposal stage will be re-entered, which is step 2.

[0052] Step 5: Submission phase, prepare the new height and broadcast the new status to the node, and then go to step 1.

[0053] like Figure 2 As shown, the five-stage consensus process is as follows:

[0054] Pre-voting stage:

[0055] 1. The node continuously monitors whether there are new proposed blocks.

[0056] 2. Before each node votes in the pre-voting phase, it needs to determine whether it is locked in on the proposal of the previous round:

[0057] (1) If yes, continue to sign and broadcast the proposal locked in the previous round and broadcast the pre-vote;

[0058] (2) Otherwise, the signature broadcasts the block described in the current round proposal and broadcasts the pre-vote;

[0059] (3) If for some reason the node does not lock or receive any proposal, it will sign and broadcast an empty pre-vote.

[0060] Pre-submission stage:

[0061] 1. For each node, it continuously receives pre-votes from the network;

[0062] 2. At the beginning of the pre-commit phase, the node collects pre-votes:

[0063] (1) If 2 / 3 of the total number of pre-votes is reached, the pre-commit vote is broadcast for this block signature, and the current node is locked on this proposal, while the previously locked proposal is released. A node can only be locked in one proposal;

[0064] (2) If it receives more than 2 / 3 of the empty pre-votes, then all previously locked proposals are released;

[0065] (3) If it does not collect more than 2 / 3 of the pre-votes, it will not lock in any proposal.

[0066] Submission stage:

[0067] 1. For each node, it continuously receives pre-committed votes from the network;

[0068] 2. In the late stage of the pre-commit phase, if the node collects more than 2 / 3 of the pre-commit votes, then the node enters the commit phase, otherwise it enters the next round of proposal phase;

[0069] The commit phase is divided into two parallel steps:

[0070] (1) A node receives pre-commit votes from more than 2 / 3 of the total number of nodes, and the node broadcasts a commit vote for the block;

[0071] (2) The node needs to collect more than 2 / 3 of the submission votes for the proposal to be passed by the pre-submission vote of the entire network.

[0072] Once both conditions are met, the node will set the submission time to the current time and will enter a new height stage, starting a new round.

[0073] At any stage of the consensus process, once a node receives more than 2 / 3 of the pre-commit votes, it will immediately enter the commit phase.

[0074] like Figure 3 As shown, the signature-based transaction distribution process is as follows:

[0075] Step 1: Take the last digit of the transaction signature and convert it into an int type, i.e. an integer number;

[0076] Step 2: Perform a modulo operation on the number of consensus nodes obtained in the previous step to get the remainder;

[0077] Step 3: Determine the consensus node object that the current transaction needs to distribute, that is, the consensus node marked as 1.

[0078] As shown in Table 1, the data storage structure of the node is as follows:

[0079]

[0080] Table 1 Node voting data storage structure

[0081] Locking mechanism: Each consensus node records and maintains the blocks that receive polka signals in each round in the node's own consensus state, that is, the proposals that it pre-submits for voting and signs, and locks them in the blocks described by the proposals; if the current node is locked on a certain block, in higher rounds, the node can only pre-vote for the block as a non-nominated node, and can only initiate proposals for the block as a nominated node

[0082] Description of the problem scenario without a locking mechanism:

[0083] The four consensus nodes A, B, C, and D reach a consensus on the polka signal for blockX in round R.

[0084] A does not know about the polka due to network reasons, so pre-commit nil, while B, C, and D pre-commit blockX;

[0085] Only D receives the full number of pre-commits, so D commits blockX, and A, B, and C enter round R+1.

[0086] In round R+1, A, B, and C submitted a new block, blockY;

[0087] The result is that a fork occurs in the absence of Byzantine nodes simply due to network problems; after the locking mechanism is introduced, B and C are locked in blockX and cannot pre-vote blockY in round R+1, and blockY cannot be passed by consensus.

[0088] The lock mechanism prevents a node from pre-committing block A in the previous round, but then pre-voting block B in the next round, thereby facilitating a polka for block B. However, the result is that once 2 / 3+ pre-commits are made to a block in a round, all nodes in the network will be locked on that block, making it impossible to reach a polka on a new block in a higher round, resulting in unavailable consensus (see the problem scenario description below). Therefore, an unlocking mechanism is needed to allow nodes to abandon locked blocks and move on to higher rounds when conditions are met.

[0089] Unlocking mechanism: When a consensus node receives a polka or nil-polka proposal with a higher block round than the one it has locked, it can unlock itself and pre-submit a voting signature for the proposal with the higher round.

[0090] Description of the problem scenario when there is only locking but no unlocking mechanism:

[0091] In round R, A and B pre-commit to blockX, and C and D pre-commit to nil-polka (empty polka). Consensus cannot be reached, and the process enters round R+1.

[0092] The proposed block in round R+1 is blockY, and C and D pre-vote for blockY;

[0093] A is a Byzantine node. Although locked in blockX, it also maliciously pre-votes for blockY, causing blockY to achieve polka.

[0094] B does not know the polka of blockY and pre-commits to nil-polka;

[0095] A is downline;

[0096] C, D pre-commit blockY;

[0097] Entering round R+2, B is locked in block X of round R, C and D are locked in block Y of round R+1, and A is offline.

[0098] Subsequent rounds can no longer reach polka, and this situation occurs when the Byzantine nodes are less than 1 / 3.

[0099] With the unlocking mechanism, if A remains offline, C and D pre-vote blockY but cannot reach polka, and A pre-vote blockX also cannot reach polka, so the three nodes will vote for nil-polka in the pre-commit stage after waiting for polka to timeout (RoundStepPrevoteWait).

[0100] The RoundStepPrevoteWait and RoundStepPrecommitWait phases indicate that +2 / 3 votes have been received for both the block and nil-polka, but that +2 / 3 votes have not yet been gathered for either the individual block or nil-polka.

[0101] The above description of the embodiments is intended to facilitate understanding and application of the present invention by those skilled in the art. It will be apparent that those skilled in the art can readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without requiring inventive effort. Therefore, the present invention is not limited to the above embodiments, and improvements and modifications made by those skilled in the art based on the disclosure of the present invention should fall within the scope of protection of the present invention.

Claims

1. A Byzantine fault-tolerant consensus method applied to blockchain, characterized in that: The following steps are involved: Obtain and parse transaction information, calculate the consensus node index based on the transaction signature, and distribute the transaction information to the transaction queue of the consensus node with the corresponding index. The consensus node generates blocks according to the preset block generation strategy, wherein the transaction information includes the transaction signature; Calculating the consensus node index based on the transaction signature includes the following steps: Convert the last digit of the transaction signature into an integer; Perform a modulo operation on the integer number by the number of consensus nodes to obtain the remainder, which is the subscript of the consensus node object that needs to be distributed for the current transaction; Each block after it is generated is added to the blockchain through a consensus process. The consensus process includes the new height stage, proposal stage, pre-voting stage, pre-submission stage, and submission stage. Locking and unlocking mechanisms are added in the pre-submission stage. In the proposal phase, a node is elected from the consensus nodes as the nominating node. The nominating node initiates a proposal for the current block to be added to the blockchain and broadcasts the proposal to other consensus nodes. In the pre-voting stage, pre-submission stage, and submission stage, each consensus node votes on the proposal. If more than 2 / 3 of the consensus nodes vote in any stage, the proposal is passed and enters the next stage of any stage. If a consensus node status change trigger request is received during the proposal phase, the gossip mechanism is used to bring all consensus nodes in the entire network to a consistent state. The change trigger request includes a timeout request, a legitimate proposal, or a situation where more than 2 / 3 of the consensus nodes vote in the pre-voting phase, pre-submission phase, and submission phase.

2. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1, characterized in that: The consensus node voting data is stored in the storage structure. The node voting data includes: node voting type, node voting block height, node current voting round, node voting block hash, voting node subscript and voting node signature, including: Node voting types include proposal, pre-voting, pre-submission, and submission, which are used to identify the voting stages, namely proposal stage, pre-voting stage, pre-submission stage, and submission stage; The block height of the node vote, used to identify the block height in the node voting proposal; The node's current voting round, which is used to identify the round of the block in the node's voting proposal; The block hash of the node vote is used to ensure that the block in the node vote proposal is unique; Voting node subscript, used to identify the voting node; The signature of the voting node is used to ensure the uniqueness of the vote.

3. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1 or 2, characterized in that: The step of selecting a node from the consensus nodes as a nominated node includes the following steps: The integer part of the current block height plus one divided by the number of blocks each node can withdraw is the height offset hf; The current round modulo the total number of consensus nodes, and the result is the round offset rf; The height offset hf and the round offset rf are summed to obtain a sum result, and the sum result is modulo the total number of consensus nodes, and the result obtained is the nominated node index pi.

4. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1, characterized in that: The pre-commit phase includes a locking mechanism and an unlocking mechanism, including the following steps: In any round, a block with more than 2 / 3 of the pre-votes is called a polka, and more than 2 / 3 of the empty pre-votes are called an empty polka. Locking mechanism: Each consensus node records and maintains the blocks received from Polkadot in each round in its own consensus state, that is, the proposals it pre-submits for voting and signs, and locks them in the blocks described by the proposals. If the current consensus node is locked on a certain block, in subsequent rounds, the consensus node can only pre-vote for blocks as a non-nominated node, and can only initiate proposals for blocks as a nominated node. Unlocking mechanism: When a consensus node receives a Polkadot or empty Polkadot proposal for a higher block round than the one it has locked, it will unlock the block and pre-submit a voting signature for the proposal for the subsequent round.

5. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1, characterized in that: The data interaction mode between nodes in the gossip mechanism includes: The first consensus node that initiates information exchange randomly contacts the second consensus node and sends information to the first consensus node. After receiving the information, the second consensus node compares and updates the data. The node with the new information is used as the trigger condition for the initiating node. The first consensus node that initiates information exchange randomly contacts the second consensus node and obtains information from it. The node with no new information is used as the trigger condition for the initiating node. The first consensus node that initiates the information exchange sends information to the selected second consensus node and obtains data from the other party at the same time to update the local data.

6. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1, characterized in that: The pre-voting stage includes the following steps: Consensus nodes constantly listen for new proposals for blocks to be added to the blockchain; After receiving the proposal, each consensus node verifies the authenticity, reliability and legitimacy of the proposal and the nominated node; After verification, the proposal is pre-voted and signed and broadcast to the network; If no valid proposal is received within the specified proposal time, the pre-vote for the proposal will be set to empty. When more than 2 / 3 of the consensus nodes approve the proposal, the pre-submission phase will begin.

7. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1, characterized in that: The pre-submission phase includes the following steps: Each consensus node continuously receives pre-votes from the network; The consensus node will sign the blocks proposed through pre-voting and broadcast the pre-commit vote. In the late pre-commit phase, if the consensus node collects more than 2 / 3 of the pre-commit votes from the total number of consensus nodes, the consensus node will enter the commit phase, otherwise it will enter the next round of proposal phase.

8. The Byzantine fault-tolerant consensus method applied to blockchain according to claim 1, characterized in that: The submission phase includes the following steps: Each consensus node continuously receives pre-commit votes from the network; If a node collects more than 2 / 3 of the pre-submission votes from the total number of consensus nodes, it broadcasts the submission vote; The node continuously collects submission votes in the network. If it collects more than 2 / 3 of the total number of consensus nodes, the submission time will be set to the current time and enter a new height stage.

9. A Byzantine fault-tolerant consensus method applied to blockchain according to claim 7, characterized in that: During the consensus process, if a node receives pre-commit votes from more than 2 / 3 of the total number of consensus nodes, the node will enter the commit phase.

Images