An Optimization Method and System for the Consensus Mechanism of Federated Blockchain

Abstract

The present invention provides an optimization method and system for the consensus mechanism of a consortium blockchain, belonging to the technical field of the consensus mechanism of a consortium blockchain. The multi-leader node mode and the multi-chain DAG storage architecture are adopted. In this mode and architecture, when a certain leader node is delayed or incorrect, other normal nodes can still continue to propose and process, without entering the node rotation mode, avoiding problems such as system stagnation, large resource consumption, and difficult view processing during leader rotation. Parallel processing of consensus transactions is realized based on multi-threading. Each replica node uses the multi-threading method to simultaneously process its own proposal actions, voting actions, and the proposal and voting behaviors of other replica nodes, and high-concurrency consensus can be achieved. At the same time, the block consensus is decoupled and optimized, and the threshold signature algorithm, two-stage consensus, block request mechanism, and expected set construction model are used to construct the consensus mechanism from two aspects of view consensus and execution consensus.

Description

Technical Field

[0001] The present invention relates to the technical field of consortium blockchain consensus mechanisms, and particularly to an optimization method and system for a consortium blockchain consensus mechanism. Background Art

[0002] With the development of technology, the consensus mechanism is a core component of the blockchain, which ensures that nodes can reach an agreement on the order and correctness of transactions in a distributed network environment. However, there are many deficiencies in the prior art. For example, in high-concurrency scenarios, the throughput is often limited and it is difficult to meet the rapidly growing demand. Many mechanisms rely on a single leader, resulting in performance degradation and vulnerability in case of system failures. Some mechanisms consume a large amount of resources during the consensus process, affecting their sustainability and efficiency. In the face of malicious nodes or network attacks, the fault tolerance of existing mechanisms is often insufficient and they are easily affected.

[0003] Therefore, there is an urgent need in the art for a technical solution that can improve the consensus efficiency on the basis of ensuring the security of the consortium chain consensus.

[0004] The information disclosed in this background art section is only for enhancing the understanding of the general background of the present invention and should not be regarded as an admission or any form of suggestion that this information constitutes prior art already known to those of ordinary skill in the art. Summary of the Invention

[0005] The purpose of the present invention is to provide a technical solution that can improve the consensus efficiency on the basis of ensuring the security of the consortium chain consensus.

[0006] To achieve the above purpose, the present invention provides the following solutions:

[0007] An optimization method for a consortium blockchain consensus mechanism, characterized by comprising:

[0008] The client sends a request to the proposal node

[0009] The proposal node makes a proposal;

[0010] Generate a proposal block and send the block to other nodes;

[0011] Other nodes perform reference block signature verification;

[0012] Other nodes update the consensus status of the upstream block on the corresponding chain;

[0013] Judge whether the upstream block is an executable block;

[0014] If it is an executable block, add it to the executable queue;

[0015] Perform an expected set construction model judgment;

[0016] Determine whether it is the expected block;

[0017] If it is the expected block, execute the block transaction of the corresponding expected set and return the execution result to the client;

[0018] If it is not the expected block, wait for subsequent block judgment.

[0019] Other nodes verify the proposed block itself;

[0020] Other nodes sign and send the signature to the proposing node;

[0021] The proposing node receives the signature and synthesizes the final signature;

[0022] The proposed block is added to storage and waits for the next consensus state update;

[0023] An optimized system for the consensus mechanism of a consortium blockchain, comprising:

[0024] A multi-leader mode and multi-chain DAG structure module for implementing parallel processing of consensus transactions based on multi-threading;

[0025] A view consensus module for achieving consistency among different replica nodes regarding the block content and its corresponding height on each chain in the storage view;

[0026] An execution consensus module for achieving consistency among different replica nodes regarding the execution of blocks.

[0027] Optionally, the multi-leader mode and multi-chain DAG structure module includes:

[0028] A node selection mechanism unit and a parallel transaction processing unit.

[0029] Optionally, the node selection mechanism unit is used when a certain node fails to initiate a proposal in a timely manner due to network latency, insufficient computing resources, or other reasons, and the remaining normal nodes of the system can still initiate new proposals in parallel and process proposal requests from other nodes; when the client encounters a transaction timeout situation during interaction with a certain node, the system allows the client to transfer the request to other nodes without waiting for the leader rotation of the current replica.

[0030] Optionally, the parallel transaction processing unit is used to enable each replica node to execute multiple tasks simultaneously in a multi-threaded architecture.

[0031] Optionally, the tasks include: processing its own block proposals, verifying and signing proposals from other nodes, and receiving and processing proposal and signature information from other replica nodes. Specifically:

[0032] When a node initiates a proposal, it can split and process different tasks in parallel. Independent threads are responsible for generating block proposals, signature verification, and signature collection. The node can also continuously receive proposals from other nodes in another thread and perform signature processing according to the threshold signature algorithm. When some threads are affected by network latency or node failures, other threads can still continue to process proposal and voting requests.

[0033] The optimized system of the consortium blockchain consensus mechanism according to claim 1, wherein the view consensus module includes a two-stage consensus protocol unit and a block request mechanism unit;

[0034] The two-stage consensus protocol unit is used to divide the block state into three consensus states: executable block, determined block, and highest block. When a proposed block is presented, the nodes in the system perform a series of verification steps to ensure the legality of the proposed block and the state of the block it references. Specifically:

[0035] The node verifies the signature situation of the previous block referenced by the proposed block, including checking whether the votes on the referenced block among nodes have reached the voting quantity threshold required for consensus, verifying the legality of each signature, and ensuring that all signatures are generated by nodes with permissions. If all these verifications pass, it is considered that the block referenced by the proposed block has reached the determined state and is marked as a "determined block". In this case, if the referenced block has been determined, then further judge the upstream block of the referenced block. It can be considered that the block proving the legality of the upstream block is recognized and valid. Therefore, all upstream blocks are considered "executable blocks", and the corresponding transaction operations can be started and added to the executable queue; when the node processes a new proposed block, it must check whether the block is on the correct blockchain branch, and the height of the new proposed block must be greater than the height of the determined block to ensure the continuity and consistency of the blockchain.

[0036] Optionally, the block request mechanism unit is used to maintain the Figure 1 consistency among nodes, specifically:

[0037] When a node processes a proposed block, it may encounter a situation where the block referenced by the proposed block is missing in its local copy storage but has collected enough signatures. This is due to network latency, synchronization problems, or view loss caused by a network attack. Although the block reference is missing, the referenced block itself has passed signature verification, indicating that the block is legal. To make up for this view loss, a block request mechanism is used to request the missing block from the proposer to help the node obtain the missing block data, thereby maintaining the Figure 1 consistency in the network.

[0038] Optionally, the execution consensus module includes an expected set construction model unit, which is used to find an expected set defined as "blocks outside the set must be proposed later than those inside the set". The specific steps are as follows:

[0039] Step 1: Sort the executable blocks according to the timestamp and add them to the executable queue;

[0040] Step 2: Determine whether the newly added block is an expected block defined as the last proposed block in the expected set. If so, execute the block and the unexecuted blocks in the expected set it constitutes; if not, wait for the judgment of subsequent blocks.

[0041] Optionally, the expected set construction model unit includes an expected block judgment unit, which is used to judge whether an execution block is an expected block. Specifically:

[0042] By comparing the timestamp of the block with other chains to determine the size of the block's timestamp. If the determined block timestamp of other chains is greater than the current block, that is, all blocks proposed earlier than the determined block on that chain have been in the view, it means there is no problem of view missing. If the determined block timestamp of a certain chain is less than the current block, then judge the state of the chain. For example, whether the chain has stopped proposing or entered a stagnant state. The basis for judging whether the chain has stopped proposing or entered a stagnant state is that the secondary reference count SID of the determined block of the judged chain by related blocks with a timestamp greater than the current block > (the number of replicas - (2*f + 1)). This is because in a distributed system, f represents the maximum number of possible faulty nodes. When the secondary reference count of related blocks with a timestamp greater than the current block exceeds this threshold, it means that more than the fault-tolerant number of nodes in the system have failed to respond effectively or advance the progress, resulting in insufficient nodes on the chain participating in block proposal or reaching a consensus, and thus entering a stagnant state.

[0043] Compared with the prior art, the present invention has the following beneficial effects:

[0044] The present invention provides an optimization method and system for the consensus mechanism of a consortium blockchain, which adopts a multi-leader node mode and a multi-chain DAG storage architecture, and realizes parallel processing of consensus transactions based on multi-threading. Decouple and optimize the block consensus, and use the threshold signature algorithm, two-stage consensus, block request mechanism, and expected set construction model to construct the consensus mechanism from two aspects of view consensus and execution consensus. It can improve the security and consensus efficiency of the consortium chain consensus mechanism on the premise of ensuring the reliability of the consensus result. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0046] Figure 1 The present invention provides a schematic diagram of the block consensus process for the embodiments.

[0047] Figure 2 The present invention provides a schematic diagram of a multi-chain DAG structure and a multi-leader mode for the embodiments.

[0048] Figure 3 The present invention provides a schematic diagram of two-stage consensus for the embodiments.

[0049] Figure 4 The present invention provides an expected set construction model for the embodiments. Detailed implementation manners

[0050] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0051] The object of the present invention is to provide a technical solution that can improve the consensus efficiency on the basis of ensuring the consensus security of the consortium blockchain.

[0052] To make the above objects, features, and advantages of the present invention more obvious and understandable, the following will further describe the present invention in detail in conjunction with the drawings and specific implementation manners.

[0053] Embodiment 1:

[0054] This embodiment provides an optimization method and system for the consensus mechanism of the consortium blockchain. This consensus system introduces a multi-leader mode and a multi-chain DAG storage architecture, realizes parallel processing of consensus transactions based on multi-threading, and introduces a node selection mechanism to replace the traditional leader rotation mechanism. At the same time, it decouples and optimizes the block consensus, and uses a threshold signature algorithm, two-stage consensus, a block request mechanism, and an expected set construction model to construct the consensus mechanism.

[0055] In addition, this consensus system decouples block consensus into view consensus and execution consensus. View consensus means that different replica nodes reach an agreement on the block content and its corresponding height on each chain in the storage view; execution consensus means that different replica nodes reach an agreement on the execution of the block; in this architecture, the nodes first reach an agreement on the order and content of transactions in the block through the view consensus mechanism, but will not execute them immediately. When the verification of the expected set construction model is met, the nodes will execute the corresponding block transactions and update their respective states. This process decouples the reaching of consensus from the execution of transactions to improve the parallel processing capability and efficiency of the system. The consensus process is as follows: Figure 1 shown.

[0056] In the consensus process, the view consensus uses the threshold signature algorithm to complete the reference block signature verification, the signature after the proposal verification is successful, and the proposal node generates a total signature (not shown in the figure). Updating the consensus status of the upstream block and the previous block, judging whether it is the expected block, etc. involve two-stage consensus and the expected set construction model. All blocks in this consensus system comply with this consensus process.

[0057] Multi-chain DAG structure and multi-leader mode:

[0058] This consensus system adopts a multi-chain architecture and multi-leader mode design, such as Figure 2 As shown. Each replica node maintains a main chain, but its stored view covers the global chain of the entire network. Each node can only initiate proposals on the chain it is responsible for, but it also needs to process proposals on other chains. Each proposal block must reference the parent block of the chain to which it belongs as the primary reference, and randomly reference confirmed blocks in other chains as secondary references.

[0059] Node selection mechanism:

[0060] When a node is unable to initiate a proposal in time due to network delays, insufficient computing resources or other reasons, the remaining normal nodes in the system can still continue to initiate new proposals in parallel and process proposal requests from other nodes. When a client encounters a transaction timeout when interacting with a node, the system allows the client to transfer the request to other nodes without waiting for the leader of the current replica to rotate.

[0061] Parallelized transaction processing:

[0062] This consensus system adopts multi-threading technology to achieve parallel processing of consensus transactions. Under the multi-threaded architecture, each replica node can execute multiple tasks simultaneously, including: processing its own block proposals, verifying and signing proposals from other nodes, and receiving and processing proposal and signature information from other replica nodes. Specifically, when a node initiates a proposal, it can split and process different tasks in parallel. Independent threads are responsible for operations such as generating block proposals, signature verification, and signature collection. At the same time, the node can continuously receive proposals from other nodes in another thread and perform signature processing according to the threshold signature algorithm. When some threads are affected by network latency or node failures, other threads can still continue to process proposals and voting requests.

[0063] View Consensus Consistency:

[0064] To ensure the Figure 1 consistency of views, this consensus system adopts a two-phase consensus mechanism, combined with the threshold signature algorithm, which further improves the efficiency and security of consensus. Threshold signature distributes the signature right to multiple nodes, and the signature will only take effect when enough nodes agree, avoiding single-point failures. In addition, this consensus system also introduces a block request mechanism, allowing nodes to request block data from other nodes when there is a view absence. This mechanism helps nodes obtain the latest block information in a timely manner, thus assisting each node in maintaining Figure 1 consistency of views.

[0065] Two-Phase Consensus Protocol:

[0066] As shown in Figure 3 the two-phase consensus, the block status can be divided into three consensus states: executable block, determined block, and highest block. When a proposed block is presented, the nodes in the system need to perform a series of verification steps to ensure the legality of the proposed block and the status of the blocks it references.

[0067] First, the node needs to verify the signature situation of the previous block referenced by the proposed block. This includes checking whether the votes on the referenced block among nodes have reached the voting quantity threshold required for consensus. At the same time, it is also necessary to verify the legality of each signature to ensure that all signatures are generated by nodes with permissions. If all these verifications pass, it can be considered that the block referenced by the proposed block has reached the determined state and is marked as a "determined block". In this case, if the referenced block has been determined, then further judge the upstream block of the referenced block. It can be considered that the block proving the legality of the upstream block is recognized and valid. Therefore, all upstream blocks are considered "executable blocks", and the corresponding transaction operations can be started and added to the executable queue. As shown in Algorithm 1:

[0068] Algorithm 1: Block Consensus Status Update Algorithm

[0069] Input block

[0070] (1) Parent block = block->get_parent()

[0071] (2) If the SIGN of the parent block is legal then

[0072] (3) Mark the parent block as a determined block

[0073] (4) For each blk in the upstream blocks do

[0074] (5) Mark blk as an executable block

[0075] (6) Add blk to the executable queue

[0076] In addition, when a node processes a new proposed block, it must also check whether the block is on the correct blockchain branch. This means that the new proposed block must reference a block on the current chain to avoid fork problems. At the same time, the height of the new proposed block (i.e., its position on the blockchain) must be greater than the height of the determined block to ensure the continuity and consistency of the blockchain.

[0077] Block request mechanism:

[0078] In this consensus system, in order to maintain the view Figure 1 consistency among nodes, a block request mechanism is introduced. When a node processes a proposed block, it may encounter a situation where the block referenced by the proposed block is missing in its local copy storage but has collected sufficient signatures. This is usually due to network latency, synchronization issues, or possibly a view missing caused by a network attack. Although the block reference is missing, the referenced block itself has passed the signature verification, indicating that the block is legal. To make up for this view missing, this consensus system introduces a block request mechanism to request the missing block from the proposer to help the node obtain the missing block data, thus maintaining the view Figure 1 consistency in the network.

[0079] Execution consensus consistency:

[0080] This consensus system introduces an expected set construction model to ensure consistent execution order in the case of node communication delays, such as Figure 4As shown in the figure, in the view composed of executable blocks, there must exist a set that satisfies the condition that "the blocks outside the set must be proposed later than the blocks inside the set". This paper calls it the expected set, which can ensure that the execution of the blocks inside the set is not affected by communication delays. The expected block refers to the last proposed block in the expected set, and the maximum expected set refers to the expected set composed of the executable blocks stored in the minimum latency replica nodes. When a certain block is judged to be an expected block, the block and earlier blocks can form an expected set. The expected set construction model is to find the expected set, and the model steps are as follows:

[0081] Step 1: Sort the executable blocks according to the timestamps and add them to the executable queue;

[0082] Step 2: Judge whether the newly added block is an expected block. If it is, execute the block and the unexecuted blocks in the expected set it forms; if not, wait for the judgment of subsequent blocks.

[0083] Note: In this consensus system, adding a block to the executable queue only maps the hash value corresponding to the block to the queue through the timestamp. When executing, the corresponding block is found from the storage according to the hash value and the corresponding transactions are executed.

[0084] This consensus system determines the size of the timestamp (Timestamp) of a block by comparing it with other chains. If the determined block timestamp of another chain is greater than this block, that is, all the blocks proposed earlier than the determined block on that chain are already in the view, it means that there is no problem of view loss. If the determined block timestamp of a certain chain is less than this block, then judge the status of the chain. For example, whether the chain has stopped proposing or has entered a stagnant state. The basis for judging whether the chain has stopped proposing or entered a stagnant state is that the secondary reference count SID of the determined block of the judged chain by related blocks with timestamps greater than this block > (the number of replicas - (2 * f + 1)). This is because in a distributed system, f represents the maximum number of possible faulty nodes. When the secondary reference count of related blocks with timestamps greater than this block exceeds this threshold, it means that more than the fault tolerance capacity of nodes in the system fail to respond or advance effectively, resulting in insufficient nodes on the chain to participate in block proposal or reach a consensus, and thus enter a stagnant state. As shown in Algorithm 2:

[0085] Algorithm 2 Expected Block Judgment Algorithm

[0086] Input the block to be judged block

[0087] Output TRUE / FALSE

[0088] (1) For all chains chain do

[0089] (2) Determine the block = getIdentifyBlock(chain)

[0090] (3) Determine the block timestamp = Determine the block -> getTimestamp()

[0091] (4) The timestamp of the block to be judged = block -> getTimestamp()

[0092] (5) if the determined block timestamp < the timestamp of the block to be judged then

[0093] (6) if Determine the block -> getSID(the timestamp of the block to be judged) < (the number of replicas - (2 * f + 1)) then

[0094] (6) return FALSE

[0095] (7) return TRUE

[0096] In this specification, each embodiment is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other. For the system disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and for the relevant parts, reference can be made to the description in the method section.

[0097] In this article, specific examples are used to elaborate on the principles and implementation manners of the present invention. The descriptions of the above embodiments are only used to help understand the method of the present invention and its core idea; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. An optimization system for the consensus mechanism of a consortium blockchain, characterized in that, Including: The multi - leader mode and multi - chain DAG structure module, which is used to implement parallelized processing of consensus transactions based on multi - threads; The view consensus module, which is used to make different replica nodes reach an agreement on the block content and its corresponding height on each chain in the storage view; The execution consensus module, which is used to make different replica nodes reach an agreement on the execution order of blocks; The view consensus module includes a two - stage consensus protocol unit and a block request mechanism unit; The two - stage consensus protocol unit is used to divide the block state into three consensus states: executable block, determined block, and highest block. When a proposed block is proposed, the nodes in the system execute a series of verification steps to ensure the legality of the proposed block and the state of the block it references. Specifically: The nodes use the threshold signature algorithm to verify the signature situation of the previous block referenced by the proposed block, including checking whether the votes of the nodes for the referenced block have reached the voting quantity threshold required by the consensus, verifying the legality of each signature, and ensuring that all signatures are generated by the nodes with permissions. If all these verifications pass, it is considered that the block referenced by the proposed block has reached the determined state and is marked as a determined block. In this case, if the referenced block has been determined, then further judge the upstream block of the referenced block. If the legality of the upstream block can be proved, the upstream block is an executable block; and the newly determined executable block is added to the executable queue; when the node processes a new proposed block, it must check whether the block is on the correct blockchain branch, and the height of the new proposed block must be greater than the height of the determined block to ensure the continuity and consistency of the blockchain; In the view composed of executable blocks, there is a set that can satisfy that the blocks outside the set must be proposed later than the blocks inside the set, which is called the expected set, and it can ensure that the execution of the blocks inside the set will not be affected by communication delays. The expected block refers to the block proposed last in the expected set, and the maximum expected set refers to the expected set composed of the executable blocks stored by the replica node with the minimum latency; when a certain block is judged to be an expected block, the block and the earlier blocks form the expected set; The execution consensus module includes an expected set construction model unit, and the expected set construction model unit is used to find the expected set. The specific steps include: Step 1: Sort the executable blocks according to the timestamp and add them to the executable queue; Step 2: Judge whether the newly added executable block is an expected block. If so, execute the block and the unexecuted blocks in the expected set it forms; if not, wait in the queue for the subsequent block judgment; The method for optimizing the consensus mechanism of the consortium blockchain using the optimization system includes: The client sends a request to the proposal node The proposal node makes a proposal; Generate a proposed block and send the proposed block to other nodes; Other nodes verify the signature situation of the referenced block of the proposed block; If the verification passes, other nodes mark the referenced block of the proposed block as a determined block; Judge whether the upstream block of the referenced block of the proposed block is an executable block; If it is an executable block, add it to the executable queue; Judge whether the executable block is an expected block; If it is an expected block, the block transaction of the expected set is executed and the execution result is returned to the client; If it is not the expected block, wait for the subsequent block judgment; Other nodes verify the proposed block; Other nodes sign and send the signature to the proposal node; The proposal node receives the signature and synthesizes the final signature; The proposal block is added to storage and waits for the next consensus state update.

2. The optimization system of the consortium blockchain consensus mechanism according to claim 1, characterized in that, The multi-leader mode and multi-chain DAG structure module include: Node selection mechanism unit and parallelized transaction processing unit.

3. The optimization system of the consortium blockchain consensus mechanism according to claim 2, wherein, The node selection mechanism unit is used to ensure that when a node is unable to initiate a proposal in time due to network delays, insufficient computing resources or other reasons, the remaining normal nodes of the system can still continue to initiate new proposals in parallel and process proposal requests from other nodes; when a client encounters a transaction timeout when interacting with a node, the system allows the client to transfer the request to other nodes without waiting for the leader of the current system to rotate.

4. The optimization system of the consortium blockchain consensus mechanism according to claim 2, characterized in that The parallelized transaction processing unit is used to enable each replica node to execute multiple tasks simultaneously under a multi-threaded architecture.

5. The optimization system of the consortium blockchain consensus mechanism according to claim 4, characterized in that, The tasks include: processing the block proposals of its own node, verifying and signing the proposals of other nodes, and receiving and processing the proposals and signature information from other nodes, specifically: Each node maintains a main chain, but its stored view covers the global chain of the entire network; each node can only initiate proposals on the chain it is responsible for, but also needs to process proposals on other chains; each proposal block must reference the parent block of the chain to which it belongs as the primary reference, and randomly reference confirmed blocks in other chains as secondary references; When a node initiates a proposal, it can split and process different tasks in parallel. Independent threads are responsible for block proposal generation, signature verification, and signature collection. The node can also continue to receive proposals from other nodes in another thread and perform signature processing according to the threshold signature algorithm. When some threads are affected by network delays or node failures, other threads can continue to process proposals and voting requests.

6. The optimization system of the consortium blockchain consensus mechanism according to claim 1, characterized in that The block request mechanism unit is used to maintain the view consistency between nodes, specifically: When a node processes a proposal block, it may encounter a situation where the block referenced by the proposal block is missing in the local copy storage of its own node but has collected a sufficient number of signatures. This is due to network delays, synchronization issues, or view loss caused by network attacks. Although the block reference is missing, the referenced block itself has passed the signature verification, indicating that the block is legal. In order to make up for this view loss, a block request mechanism is used to request the missing block from the proposer to help the node obtain the missing block data, thereby maintaining view consistency in the network.

Images