A parallel consensus method and system for dynamically adjusting broadcast and consensus strategies

Abstract

The present application relates to the technical field of blockchain, and provides a parallel consensus method and system for dynamically adjusting broadcast and consensus strategies, which comprises: selecting a broadcast strategy and a consensus strategy according to the relationship between the accumulated transaction volume in the transaction pool and the maximum transaction capacity in the block, and the number of available consensus nodes in the blockchain network; broadcasting the block according to the selected broadcast strategy, and distributing the selected consensus strategy to the consensus nodes, so that each consensus node performs a block consensus task based on the consensus strategy. The computing resources in the network are fully utilized, and the consensus performance requirements in different scenarios can be dynamically adapted.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a parallel consensus method and system for dynamically adjusting broadcast and consensus strategies. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Consensus mechanisms are the mechanisms and methods used in the blockchain technology field to ensure the consistency of blockchain ledger data. Consensus performance is a crucial factor affecting blockchain transaction throughput and block upload speed. To adapt to the consensus performance requirements of different scenarios, existing technologies typically design or select consensus mechanisms based on scenario characteristics and needs, choosing different consensus mechanisms for different scenarios based on pluggable consensus components. For example, Raft consensus is used in scenarios with relatively trustworthy environments and higher performance requirements, while BFT consensus is used in scenarios with complex environments and high trust requirements. In open consortium blockchain scenarios, different consortium members, such as blockchain builders, operators, and users, can join and leave the blockchain network at any time, leading to changes in the blockchain network's consensus environment. This includes changes in the number of blockchain nodes and significant fluctuations in the frequency of transaction requests received within the chain over different time periods. In situations where the blockchain network environment changes rapidly, it is difficult to switch consensus strategies in a timely manner to cope with dynamically changing scenarios using pluggable methods. Moreover, open consortium blockchain networks typically have high requirements for blockchain transaction throughput, and pluggable consensus mechanisms cannot dynamically adapt to changes in transaction throughput requirements. Summary of the Invention

[0004] To address the technical problems existing in the background art, the present invention provides a parallel consensus method and system that dynamically adjusts broadcast and consensus strategies, making full use of network computing resources and dynamically adapting to the consensus performance requirements of different scenarios.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] The first aspect of the present invention provides a parallel consensus method for dynamically adjusting broadcast and consensus strategies, comprising:

[0007] Based on the relationship between the accumulated pending transactions in the transaction pool and the maximum transaction capacity in the block, as well as the number of consensus nodes available in the blockchain network, the broadcast strategy and consensus strategy are selected.

[0008] Based on the selected broadcasting strategy, the block is broadcast and the selected consensus strategy is distributed to the consensus nodes so that each consensus node can execute the block consensus task based on the consensus strategy.

[0009] Furthermore, when the number of transactions to be processed is less than or equal to the maximum transaction capacity in the block, the consensus strategy is PBFT consensus and the broadcast strategy is the full block broadcast strategy.

[0010] Furthermore, when the amount of transactions to be processed is greater than the maximum transaction capacity in a block, but less than or equal to a preset multiple of the maximum transaction capacity, the consensus strategy is PBFT consensus, and the broadcast strategy is a block broadcasting processing mechanism that broadcasts the block header and segments the block body.

[0011] Furthermore, when the amount of transactions to be processed is greater than the maximum transaction capacity in the block, but less than or equal to a preset multiple of the maximum transaction capacity, the block capacity is expanded, and the block transaction capacity is adjusted to a preset multiple of the maximum transaction capacity before a single block is constructed.

[0012] Furthermore, when the number of transactions to be processed exceeds a preset multiple of the maximum transaction capacity, and the number of consensus nodes in the blockchain network does not reach the threshold, the consensus strategy selects the block parallel consensus processing strategy, and the broadcast strategy selects the broadcast processing mechanism that broadcasts the block header and the transaction list in the block.

[0013] Furthermore, when the number of transactions to be processed exceeds a preset multiple of the maximum transaction capacity, and the number of consensus nodes in the blockchain network reaches a threshold, the consensus strategy selects a random grouping parallel processing strategy, and the broadcast strategy selects a broadcast processing mechanism that broadcasts the block header and the transaction list in the block.

[0014] Furthermore, when the number of transactions to be processed exceeds a preset multiple of the maximum transaction capacity, blocks are constructed in parallel based on the read-write dependencies between transactions.

[0015] A second aspect of the present invention provides a parallel consensus system for dynamically adjusting broadcast and consensus strategies, comprising:

[0016] The decision module is configured to select a broadcast strategy and a consensus strategy based on the relationship between the accumulated pending transactions in the transaction pool and the maximum transaction capacity in the block, as well as the number of consensus nodes available in the blockchain network.

[0017] The network communication module is configured to broadcast blocks according to the selected broadcast strategy;

[0018] The consensus execution module is configured to distribute the selected consensus policy to the consensus nodes so that each consensus node can execute block consensus tasks based on the consensus policy.

[0019] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a parallel consensus method for dynamically adjusting broadcast and consensus strategies as described above.

[0020] A fourth aspect of the present invention provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a parallel consensus method for dynamically adjusting broadcast and consensus strategies as described above.

[0021] Compared with the prior art, the beneficial effects of the present invention are:

[0022] This invention provides a parallel consensus method that dynamically adjusts broadcast and consensus strategies. It dynamically adjusts the block broadcast and consensus strategies based on the accumulated amount of transactions to be processed and the number of consensus nodes in the network, making full use of the computing resources in the network and dynamically adapting to the consensus performance requirements under different scenarios.

[0023] This invention provides a parallel consensus method that dynamically adjusts broadcast and consensus strategies. It employs mechanisms such as parallel block construction and parallel consensus to process blocks in parallel, thereby significantly improving consensus processing performance and meeting the high transaction throughput requirements of open consortium blockchain networks. Attached Figure Description

[0024] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0025] Figure 1 This is a flowchart illustrating the selection of broadcast and consensus strategies in Embodiment 1 of the present invention;

[0026] Figure 2 This is a flowchart of the block parallel consensus processing strategy of Embodiment 1 of the present invention;

[0027] Figure 3 This is a flowchart of the random grouping parallel processing strategy of Embodiment 1 of the present invention;

[0028] Figure 4 This is a schematic diagram of the data flow of a parallel consensus method for dynamically adjusting broadcast and consensus strategies according to Embodiment 1 of the present invention. Detailed Implementation

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0030] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0031] Example 1

[0032] This embodiment provides a parallel consensus method for dynamically adjusting broadcasting and consensus strategies.

[0033] The parallel consensus method for dynamically adjusting broadcasting and consensus strategies provided by this embodiment can automatically identify changes in the number of nodes, request volume and other conditions in a blockchain network to dynamically adjust the consensus strategy, and provide high-performance consensus performance under different scenarios.

[0034] In the parallel consensus method for dynamically adjusting broadcasting and consensus strategies provided by this embodiment, the master node of consensus is responsible for constructing blocks and consensus tasks, and selects the block broadcasting strategy and consensus strategy according to the accumulated pending transactions in the transaction pool of the current consensus master node and the number of available consensus nodes in the blockchain network. The consensus master node can be elected through a rotating block-producing mechanism or a random election mechanism, and serves as the master node within a limited number of consensus rounds.

[0035] Before each round of consensus starts, the consensus master node selects the block broadcasting strategy and consensus strategy according to the relationship between txNum (the number of accumulated pending transactions in the master node's transaction pool) and blockTxNum (the maximum number of transactions that can be carried in each block), as well as conPeerNum (the number of available consensus nodes). Specifically, when txNum ≤ blockTxNum, the conventional PBFT consensus is performed on the block, and a complete block broadcasting method is adopted for block broadcasting; when blockTxNum < txNum ≤ blockTxNum * 3, the maximum number of transactions in the block is temporarily adjusted to blockTxNum * 3 for block construction and consensus, and the block broadcasting strategy is adjusted at the same time: instead of broadcasting the constructed complete block, the master node broadcasts the block header information and broadcasts the block body in sections, so as to avoid communication pressure caused by large block broadcasting; when txNum > blockTxNum * 3, the master node performs parallel block construction, and a block parallel consensus processing strategy is selected when the number of consensus nodes is limited. If the number of consensus nodes in the network reaches the threshold, a random group parallel consensus processing strategy is selected to further improve the utilization rate of consensus computing resources, and the block broadcasting strategy is adjusted to broadcasting key information of the block header and the transaction list in the block at the same time. The threshold for the number of consensus nodes can be set to twice the minimum number of nodes for PBFT consensus when a certain fault tolerance rate is satisfied, that is, 8 consensus nodes (PBFT consensus with 4 consensus nodes can support 1 node fault tolerance).

[0036] After the master node determines the consensus strategy, it broadcasts the block according to the selected block broadcasting strategy, and distributes the selected consensus strategy and consensus tasks together to other consensus nodes through consensus messages, so that each consensus node executes the consensus strategy based on the consensus strategy selected by the master node and the distributed tasks. After a round of consensus tasks assigned by the master node is completed, the next round of consensus strategy is determined and the next round of consensus is started according to the current accumulated situation of the transaction pool of the master node, the number of consensus nodes and other conditions.

[0037] In this parallel block construction process, the master node pulls transactions from the transaction pool and divides them into multiple groups based on their read-write dependencies. Specifically, if all transactions have no read-write dependencies, they are divided according to the principle that the number of transactions in each group is less than or equal to `blockTxNum`. Each group of transactions is used to construct a block, and block numbers are assigned to each block sequentially based on the current block height. These blocks can reach consensus in parallel. If transactions have read-write dependencies, the dependent transactions and mutually dependent transactions are placed in the same block, and the block height is assigned to each block with the current block number incremented by one. This block is executed first and is called the pre-dependency block. Other transactions without dependencies are divided into multiple blocks that can be executed in parallel, based on the principle that the number of transactions in each group is less than or equal to `blockTxNum`. The block height is assigned to each block sequentially based on the pre-dependency block number. The consensus master nodes perform the construction tasks of the pre-divided blocks in parallel. The block construction tasks communicate with each other. After the previous block construction task is completed, the hash of that block is written into the block header of the next block as the parent block hash, and so on, to complete the construction of all blocks in sequence.

[0038] The block parallel consensus processing strategy involves the consensus master node broadcasting its chosen block parallel processing strategy and block allocation strategy to all consensus nodes. All consensus nodes first achieve consensus on dependent blocks. Once the consensus on dependent blocks is consistently uploaded to the chain, parallel consensus on other undependent blocks is then performed. During parallel consensus on undependent blocks, before writing the execution result of each block, the previous block's upload status is checked. The block is written only after the previous block has been successfully uploaded, ensuring the order of block uploads. If any block consensus fails, blocks with block numbers higher than the failed block's height in this round of consensus will not be uploaded to the chain.

[0039] The random grouping parallel processing strategy involves the following steps: When there are enough consensus nodes in the blockchain network, after each consensus node completes the consensus and on-chain processing of its preceding dependent blocks, the master node randomly divides the consensus nodes in the network into multiple consensus groups, with each group having at least four consensus nodes. Blocks that can be consensused in parallel are evenly distributed among different consensus groups for group consensus, with each group performing PBFT consensus. After each group of consensus nodes completes consensus on one block within its group, it broadcasts the consensus-passed block and execution result to all consensus nodes. Each consensus node verifies whether the signature information in the block is consistent with the consensus task assigned by the master node and caches the result. Once the preceding blocks of this block have completed consensus and been on-chain, the block and its execution result are written to the blockchain. If any block consensus fails, blocks with block numbers higher than the height of the failed block in this round of consensus will not be written to the blockchain.

[0040] This embodiment provides a parallel consensus method for dynamically adjusting broadcast and consensus strategies, such as... Figure 4 As shown in the figure, the transaction pool module receives and caches transaction request messages, and deletes transactions after the transactions are chained or fail; the block construction module pulls transactions in batches from the transaction pool, and constructs a single block or constructs blocks in parallel according to the number of transactions and the read-write dependencies between transactions; the consensus strategy decision-making module decides the consensus processing strategy to be adopted according to the accumulated number of pending transactions and the number of consensus nodes in the blockchain network, and performs consensus grouping of consensus nodes and distribution of block consensus tasks in the random grouping consensus processing strategy; the broadcast strategy decision-making module adjusts the block broadcast strategy according to the accumulated number of pending transactions; the network communication module performs inter-node message communication such as transaction broadcast, block broadcast and consensus message broadcast; the consensus execution module executes consensus tasks according to the consensus processing strategy selected by the current master node; the block execution module executes transactions in the block and caches the execution results; after the block execution is successful, the block chaining module checks whether the predecessor block of the block has been chained, and if it has been completed, performs the chaining writing of the currently verified block.

[0041] Wherein, in Figure 1 As shown, the method for selecting a broadcast strategy and a consensus strategy is as follows:

[0042] Step 201: the consensus master node pulls transactions in batches from the transaction pool;

[0043] Step 202: judge whether the number of pending transactions (referred to as txNum) is less than or equal to the maximum transaction capacity in a block (referred to as blockTxNum), if yes, go to step 2021, otherwise go to step 203;

[0044] Step 2021: the block construction module of the master node constructs a single block;

[0045] Step 2022: the consensus decision-making module of the master node selects the conventional PBFT consensus, publishes the consensus strategy and tasks through the network communication module, and starts the conventional PBFT consensus;

[0046] Step 2023: the broadcast strategy decision-making module selects the complete block broadcast strategy, constructs a complete block broadcast message, and performs block broadcast;

[0047] Step 203: judge whether blockTxNum < txNum ≤ blockTxNum*3, if yes, go to step 2031, otherwise go to step 204;

[0048] Step 2031: the block construction module of the master node expands the block capacity, adjusts the block transaction capacity to blockTxNum*3, and constructs a single block;

[0049] Step 2032: The consensus strategy decision module selects the conventional PBFT consensus, publishes the consensus strategy and tasks through the network communication module, and starts the conventional PBFT consensus;

[0050] Step 2033: The broadcast strategy decision module selects the block broadcast processing mechanism of broadcast block header and segmented broadcast block body to broadcast the block;

[0051] Step 204: The block building module constructs blocks in parallel based on the read-write dependencies between transactions;

[0052] Step 2041: Determine whether the number of consensus nodes in the blockchain network has not reached the threshold n. If yes, proceed to step 2042; otherwise, proceed to step 2043. The threshold for the number of consensus nodes can be set to twice the minimum number of nodes required for PBFT consensus to meet a certain fault tolerance rate, i.e., 8 consensus nodes (4 consensus nodes for PBFT consensus can support 1 node fault tolerance).

[0053] Step 2042: The consensus strategy decision module selects the block parallel consensus processing strategy, publishes the consensus strategy and task through the network communication module, declares the range of block numbers involved in this round of block parallel consensus, as well as the preceding dependent blocks and parallel consensus blocks in the consensus task, and performs block parallel consensus.

[0054] Step 2043: The consensus strategy decision module selects a random grouping parallel processing strategy to divide the consensus nodes in the network into multiple consensus groups. The consensus strategy and tasks are published through the network communication module. The consensus tasks declare the range of block numbers involved in the parallel consensus of this round of blocks, the preceding dependent blocks and the blocks that can be consensused in parallel, as well as the block tasks that each consensus group is responsible for. Multiple consensus groups are responsible for different blocks to achieve parallel consensus.

[0055] Step 2044: The broadcast strategy decision module selects a broadcast processing mechanism that broadcasts the block header and the transaction list in the block;

[0056] Step 205: Based on the selected consensus strategy and broadcast strategy, achieve consensus on the block and execute it on the chain.

[0057] Specifically, the block parallel consensus processing strategy, such as Figure 2 As shown, it includes the following steps:

[0058] Step 301: The consensus master node publishes to all consensus nodes the block parallel consensus processing strategy adopted in this round of consensus, as well as the scope of blocks involved in this round of consensus and the scope of previous blocks;

[0059] Step 302: The consensus master node broadcasts the blocks constructed by the master node in parallel through the network communication module;

[0060] Step 303: After each consensus node receives the broadcast block, the consensus execution module first performs consensus on the preceding dependent blocks and caches other pending blocks;

[0061] Step 304: After the consensus of the preceding dependent blocks is passed, the block execution module executes and verifies the block. After the verification is passed, the block on-chain module writes the block and execution result, and deletes the on-chain transactions from the transaction pool.

[0062] Step 305: Before writing the preceding dependent block to the chain, verify whether the preceding block of this block has been written to the chain, and verify whether the information such as the parent block hash in the block is correct. If the verification passes, proceed to step 306; otherwise, proceed to step 313.

[0063] Step 306: The block on-chain module writes the preceding dependent blocks and execution results;

[0064] Step 307: The consensus execution modules of each consensus node execute parallel consensus blocks other than the pre-consensus dependent blocks;

[0065] Step 308: When a block consensus is passed, the block execution module executes and verifies the block, and caches the execution result;

[0066] Step 309: Determine whether the preceding block of this block has been written to the chain. If yes, proceed to step 311; otherwise, proceed to step 310.

[0067] Step 310: Wait for the preceding block of this block to be written to the chain;

[0068] Step 311: Verify whether the information such as the parent block hash in this block is correct. If the verification passes, proceed to step 312; otherwise, proceed to step 313.

[0069] Step 312: The block on-chain module writes the block and execution result, deletes the transactions already on-chain in the transaction pool, and repeats the steps below step 308 until all blocks are on-chain.

[0070] Step 313: If a block fails verification, cancel the consensus on-chaining of that block and subsequent blocks, and each node re-elects a master node for subsequent consensus.

[0071] Specifically, the random grouping parallel processing strategy, such as Figure 3 As shown, it includes the following steps:

[0072] Step 401: The consensus master node publishes to all consensus nodes the block parallel consensus processing strategy adopted in this round of consensus, as well as the scope of blocks involved in this round of consensus and the scope of previous blocks;

[0073] Step 402: The consensus master node randomly divides the consensus nodes in the network into multiple consensus groups, and assigns different block consensus tasks that can be agreed upon in parallel to each consensus group. The consensus master node broadcasts the previous block and the block consensus tasks of each consensus group to the corresponding consensus nodes through the network communication module.

[0074] Step 403: After each consensus node receives the broadcast block, the consensus execution module first performs consensus on the preceding dependent blocks and caches other pending blocks;

[0075] Step 404: After the consensus of the preceding dependent blocks is passed, the block execution module executes and verifies the block. After the verification is passed, the block on-chain module writes the block and execution result, and deletes the on-chain transactions from the transaction pool.

[0076] Step 405: Before writing the preceding dependent block to the chain, verify whether the preceding block of this block has been written to the chain, and verify whether the information such as the parent block hash in the block is correct. If the verification passes, proceed to step 406; otherwise, proceed to step 412.

[0077] Step 406: The block on-chain module writes the preceding dependent blocks and execution results;

[0078] Step 407: Each consensus group, according to the consensus task assigned by the master node, performs parallel processing of the parallelizable blocks other than the preceding dependent blocks assigned by the consensus task.

[0079] Step 408: When a consensus group passes a block, the block execution module executes and verifies the block, and caches the execution result;

[0080] Step 409: Determine whether the preceding block of this block has been written to the chain. If yes, proceed to step 411; otherwise, proceed to step 410.

[0081] Step 411: Verify whether the information such as the parent block hash in this block is correct. If the verification passes, proceed to step 413; otherwise, proceed to step 412.

[0082] Step 412: If a block fails verification, cancel the consensus on-chaining of that block and subsequent blocks, and each node re-elects a master node for subsequent consensus.

[0083] Step 413: The block on-chain module writes the block and execution result, and deletes the on-chain transactions from the transaction pool;

[0084] Step 414: The node that has written the block broadcasts the block and the execution result to consensus nodes outside the consensus group;

[0085] Step 415: Receive the node signature carried in the node verification message of the broadcast block and execution result, and verify whether the identity of the signing node is consistent with the identity of the node assigned by the master node to be responsible for the consensus of this block. If they are consistent, proceed to step 416; otherwise, do not process the message.

[0086] Step 416: The node writes the received block and execution result onto the chain.

[0087] Example 2

[0088] This embodiment provides a parallel consensus system that dynamically adjusts broadcast and consensus strategies, such as Figure 4 As shown, it specifically includes:

[0089] The transaction pool module is configured to receive and cache transaction request messages, and delete transactions after they are put on the blockchain or fail.

[0090] The block building module is configured to: pull transactions in batches from the transaction pool, and build a single block or build blocks in parallel based on the number of transactions and the read / write dependencies between transactions;

[0091] The decision-making module is configured to select a broadcast strategy and a consensus strategy based on the relationship between the accumulated pending transactions in the transaction pool and the maximum transaction capacity in a block, as well as the number of available consensus nodes in the blockchain network. The decision-making module includes a consensus strategy decision-making module and a broadcast strategy decision-making module. The consensus strategy decision-making module is configured to determine the consensus processing strategy to be adopted based on the accumulated pending transactions and the number of consensus nodes in the blockchain network, and to perform consensus grouping of consensus nodes and distribution of block consensus tasks within the random grouping consensus processing strategy. The broadcast strategy decision-making module is configured to adjust the block broadcast strategy based on the accumulated pending transactions.

[0092] The network communication module is configured to perform inter-node message communication such as transaction broadcasting, block broadcasting, and consensus message broadcasting.

[0093] The consensus execution module is configured to execute consensus tasks according to the consensus processing strategy selected by the current master node.

[0094] The block execution module is configured to execute transactions in a block and cache the execution results.

[0095] The block on-chain module is configured to: after a block is successfully executed, verify whether the preceding block has been completed on the chain; if it has, then write the currently verified block onto the chain.

[0096] It should be noted that each module in this embodiment corresponds one-to-one with each step in Embodiment 1, and their specific implementation processes are the same.

[0097] Example 3

[0098] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a parallel consensus method for dynamically adjusting broadcast and consensus strategies as described in Embodiment 1 above.

[0099] Example 4

[0100] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the parallel consensus method for dynamically adjusting broadcast and consensus strategies as described in Embodiment 1 above.

[0101] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0102] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0103] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0104] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0105] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0106] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A parallel consensus method for dynamically adjusting broadcast and consensus strategies, characterized in that, include: Based on the relationship between the accumulated pending transactions in the transaction pool and the maximum transaction capacity in a block, as well as the number of available consensus nodes in the blockchain network, a broadcast strategy and a consensus strategy are selected. Specifically, when the pending transaction volume is less than or equal to the maximum transaction capacity in a block, the consensus strategy is PBFT consensus, and the broadcast strategy is a full block broadcast strategy. When the pending transaction volume is greater than the maximum transaction capacity in a block, but less than or equal to a preset multiple of the maximum transaction capacity, the consensus strategy is PBFT consensus, and the broadcast strategy is a block broadcast processing mechanism that broadcasts the block header and segmented block body. When the pending transaction volume is greater than a preset multiple of the maximum transaction capacity, and the number of consensus nodes in the blockchain network has not reached a threshold, the consensus strategy is a block parallel consensus processing strategy, and the broadcast strategy is a broadcast processing mechanism that broadcasts the block header and the transaction list within the block. When the pending transaction volume is greater than a preset multiple of the maximum transaction capacity, and the number of consensus nodes in the blockchain network has reached a threshold, the consensus strategy is a random grouping parallel processing strategy, and the broadcast strategy is a broadcast processing mechanism that broadcasts the block header and the transaction list within the block. Based on the selected broadcasting strategy, the block is broadcast and the selected consensus strategy is distributed to the consensus nodes so that each consensus node can execute the block consensus task based on the consensus strategy.

2. The parallel consensus method for dynamically adjusting broadcast and consensus strategies as described in claim 1, characterized in that, When the number of transactions to be processed exceeds the maximum transaction capacity in a block, but is less than or equal to a preset multiple of the maximum transaction capacity, the block capacity is expanded. After adjusting the block transaction capacity to a preset multiple of the maximum transaction capacity, a single block is constructed.

3. The parallel consensus method for dynamically adjusting broadcast and consensus strategies as described in claim 1, characterized in that, When the number of transactions to be processed exceeds a preset multiple of the maximum transaction capacity, blocks are constructed in parallel based on the read-write dependencies between transactions.

4. A parallel consensus system that dynamically adjusts broadcast and consensus strategies, characterized in that, include: The decision-making module is configured to: select a broadcast strategy and a consensus strategy based on the relationship between the accumulated pending transaction volume in the transaction pool and the maximum transaction capacity in a block, as well as the number of available consensus nodes in the blockchain network; specifically, when the pending transaction volume is less than or equal to the maximum transaction capacity in a block, the consensus strategy is PBFT consensus, and the broadcast strategy is the full block broadcast strategy; when the pending transaction volume is greater than the maximum transaction capacity in a block, but less than or equal to a preset multiple of the maximum transaction capacity, the consensus strategy is PBFT consensus, and the broadcast strategy is a block broadcast processing mechanism that broadcasts the block header and segmented block body; when the pending transaction volume is greater than a preset multiple of the maximum transaction capacity, and the number of consensus nodes in the blockchain network has not reached a threshold, the consensus strategy is a block parallel consensus processing strategy, and the broadcast strategy is a broadcast processing mechanism that broadcasts the block header and the transaction list in the block; when the pending transaction volume is greater than a preset multiple of the maximum transaction capacity, and the number of consensus nodes in the blockchain network has reached a threshold, the consensus strategy is a random grouping parallel processing strategy, and the broadcast strategy is a broadcast processing mechanism that broadcasts the block header and the transaction list in the block. The network communication module is configured to broadcast blocks according to the selected broadcast strategy; The consensus execution module is configured to distribute the selected consensus policy to the consensus nodes so that each consensus node can execute block consensus tasks based on the consensus policy.

5. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps in the parallel consensus method for dynamically adjusting broadcast and consensus strategies as described in any one of claims 1-3.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the parallel consensus method for dynamically adjusting broadcast and consensus strategies as described in any one of claims 1-3.

Images