Blockchain consensus method and device supporting multi-node parallel proposal

Abstract

This invention discloses a blockchain consensus method and apparatus supporting multi-node parallel proposals, applied to a blockchain system composed of multiple nodes. The method includes: in the current time period of the current consensus view, multiple nodes, acting as proposal nodes, construct blocks respectively; each proposal node determines the payload of a block based on its type and a locally stored set of transaction proof digests, and broadcasts a proposal message containing that block to all nodes; each node, acting as a verification node, collects blocks from all proposal messages that satisfy the asynchronous collection barrier; for each received block, it generates a voting message by combining the block type with a locally stored time-based voting status table, and sends it to the proposal node that generated the block or the main coordinating node of the current consensus view, updating the locally stored time-based voting status table; all nodes collaboratively perform a global confirmation and commit operation on the main chain block. This invention offers high consensus efficiency.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and cloud service technology, and in particular to a blockchain consensus method and apparatus that supports parallel proposals from multiple nodes. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] In the entire execution of the BFT (Byzantine Fault Tolerance) protocol, the block proposal message phase is the most resource-intensive stage. Specifically, the master coordinating node needs to broadcast block proposal messages to all nodes in the network, and the amount of data carried by these messages typically far exceeds that of other types of interactive messages. Since the block proposal message is a necessary prerequisite for consensus, other communication operations in the protocol (such as the vote collection process between nodes) objectively result in redundant network bandwidth consumption. The core function of these communication steps is only to confirm the block order consensus; they do not use bandwidth resources to improve system throughput and scalability. These operations are defined as "bandwidth-independent steps."

[0004] However, current mainstream BFT derivative protocols all contain varying degrees of bandwidth-decoupled steps. In these bandwidth-redundant steps, nodes must wait to collect a sufficient number of votes (usually meeting a threshold of more than 2 / 3 of the total number of nodes in the system) before they can enter the next stage of the consensus process, resulting in network bandwidth not being fully utilized for throughput improvement and scalability optimization. Summary of the Invention

[0005] This invention provides a blockchain consensus method supporting multi-node parallel proposals, applicable to blockchain systems composed of multiple nodes. It can fully utilize the network bandwidth of the master coordinating node based on network latency, improving consensus efficiency. When deployed in distributed systems such as blockchain, it can significantly improve system efficiency, throughput, average transaction latency, and other performance metrics, including: In the current time period of the current consensus view, multiple nodes, acting as proposal nodes, construct blocks respectively. The types of blocks include transaction blocks used to confirm transaction sets and main chain blocks used to confirm the main chain status. Each proposing node determines the payload of a block based on its type and the set of transaction proof digests stored locally, and broadcasts the proposal message containing that block to all nodes. Each node, acting as a verification node, collects blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that generated the block or the main coordinating node of the current consensus view, updating the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected. All nodes work together to perform a global confirmation and commit operation on the main chain blocks.

[0006] This invention also provides a blockchain consensus device that supports parallel proposals from multiple nodes. Applied to a blockchain system composed of multiple nodes, it can fully utilize the network bandwidth of the main coordinating node based on network latency, thereby improving consensus efficiency. When deployed in distributed systems such as blockchain, it can significantly improve system efficiency, throughput, average transaction latency, and other performance metrics. The proposal module is used to construct blocks by multiple nodes as proposal nodes in the current time period of the current consensus view. The types of blocks include transaction blocks for confirming transaction sets and main chain blocks for confirming the main chain status. Each proposal node determines the payload of the block according to the type of each block and the set of transaction proof digests stored locally, and broadcasts the proposal message containing the block to all nodes. The voting module is used by each node as a validator to collect blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that produced the block or the main coordinating node of the current consensus view, and updates the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected. The submission module is used by all nodes to collaboratively perform global confirmation and submission operations on the main chain blocks.

[0007] This invention also 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 computer program, it implements the aforementioned blockchain consensus method that supports multi-node parallel proposals.

[0008] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned blockchain consensus method supporting multi-node parallel proposals.

[0009] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned blockchain consensus method supporting multi-node parallel proposals.

[0010] In this embodiment of the invention, by designing a multi-node parallel proposal, the traditional BFT protocol's mode of a single master node broadcasting block proposals is extended to a mode where all nodes simultaneously participate in block construction and proposal broadcasting. This allows network bandwidth to be concentrated on carrying core data such as block proposals, reducing redundant bandwidth consumption in unrelated steps and achieving efficient utilization of bandwidth resources. With the help of time-based parallel proposals and asynchronous collection barrier mechanisms, each node can synchronously initiate block proposals based on its local clock, advancing consensus without waiting for a pre-voting process. This breaks through the bottleneck of the "waiting for voting threshold" process in traditional BFT protocols, significantly shortening the consensus cycle and improving overall execution efficiency. By differentiating the payload logic of main chain blocks and transaction blocks, block data adapts to different consensus requirements. Combined with the dynamic updates of the time-based voting status table, after deployment of the blockchain system, the overall system performance and transaction throughput can be improved simultaneously, while reducing average transaction latency, achieving synergistic optimization of multiple core indicators. This solution is compatible with the architectural characteristics of permissioned blockchains and hybrid blockchains. It retains the fault tolerance and attack resistance of the BFT protocol, while enhancing the scalability of the system through a multi-node parallel mechanism. It can adapt to more types of distributed application scenarios and has broader promotional value. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart of a blockchain consensus method supporting multi-node parallel proposals in an embodiment of the present invention; Figure 2 This is a schematic diagram of the message flow of a blockchain consensus method supporting multi-node parallel proposals in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a blockchain consensus device that supports parallel proposals from multiple nodes in an embodiment of the present invention; Figure 4This is another schematic diagram of the structure of a blockchain consensus device that supports parallel proposals from multiple nodes in an embodiment of the present invention; Figure 5 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0013] In this embodiment of the invention, the blockchain consensus method supporting multi-node parallel proposals adopts a mode in which all (or more) nodes produce blocks in parallel. The protocol is based on time periods (sl), with each time period corresponding to a view and a unique pre-set master coordinating node (Proposer). All correct nodes can obtain the identity of the master coordinating node of view v by calculating Proposer(v). Within any time period, the master coordinating node can propose a main chain block (ml block), and nodes can propose transaction blocks (tr blocks); all nodes simultaneously act as voters for any block proposed by any node.

[0014] The main advantages of PICHU-DAG compared with other BFT protocols are: (1) At any stage of the protocol (including the regular stage and view change), the main coordinating node proposes blocks in a timed manner without waiting for the collection of votes; (2) The PICHU-DAG protocol is provably secure; (3) PICHU-DAG supports multiple nodes to jointly produce blocks, making full use of the network bandwidth of all nodes.

[0015] Specifically, the data type of PICHU-DAG is similar to that of PICHU-HS, but for the multi-master proposal paradigm, we propose new rules for block proposal, verification, and submission. Regarding protocol details: (1) During the block proposal phase, each (or more) node produces blocks in parallel based on its local clock. In any given time period, non-primary coordinating nodes can only propose transaction blocks, while the primary coordinating node can decide whether to propose a transaction block or a main chain block based on the received NEW-VIEW message; (2) New block payloads were proposed for different types of blocks. The payload of a transaction block is a batch of transactions, while the payload of a main chain block is the quorum certificate of multiple transaction blocks. (3) During the block voting phase, new voting rules were designed for different types of blocks. Nodes are allowed to safely vote on transaction blocks that do not carry votes, and additional voting rules are proposed for main chain blocks, especially for main chain blocks that do not arrive at the correct time, to ensure that they receive enough votes without compromising protocol security. Each node simultaneously records its votes on transaction blocks and forms QCs, which are stored in the transaction proof digest set trQCs. The voting message contains the latest trQCs stored locally; (4) New block submission rules were proposed for submitting special payloads (multiple QCs) of the main chain blocks; PICHU-DAG will be described in detail below.

[0016] Figure 1 The flowchart of a blockchain consensus method supporting multi-node parallel proposals in an embodiment of the present invention includes: Step 101: In the current time period of the current consensus view, multiple nodes, as proposal nodes, construct blocks respectively. The types of blocks include transaction blocks for confirming transaction sets and main chain blocks for confirming the main chain status. Step 102: Each proposing node determines the payload of the block based on the type of each block and the set of transaction proof digests stored locally, and broadcasts the proposal message containing the block to all nodes. Step 103: Each node, acting as a verification node, collects blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that generated the block or the main coordinating node of the current consensus view, updating the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected. Step 104: All nodes collaboratively perform a global confirmation and commit operation for the main chain block.

[0017] PICHU-DAG employs a multi-master node parallel proposal paradigm based on a local timer. At the start of each time period t, each node proposes a proposal message containing block b and sends it to all nodes (only the master coordinating node can propose ml blocks). When a node receives a valid proposal message (b.sl≤t), it votes on b based on its type and time period and sends it to the corresponding proposing node. At the beginning of time period t, any node starts a timer Δ. After the timer expires, time period t+1 begins.

[0018] Each step is described in detail below.

[0019] Figure 2 This is a message flow diagram of a blockchain consensus method supporting parallel proposals by multiple nodes in an embodiment of the present invention. In this embodiment, several symbols are used to simplify the above representation: bx represents the x field of block b, for example, b.height represents the height of block b.

[0020] Before executing the method proposed in this embodiment of the invention for the first time, the time period sl can be initialized to the current time period csl=1, the view number view can be initialized to the current view number cview=1, the transaction proof digest set trQCs and the time-based voting status table B can be initialized to be n-dimensional vectors (each position in the vector is a stop marker), and the global quorum certificate globalQC and the last voted main chain block B can be initialized. ml for The consensus view change symbol fl is set to 1. Proposer(v) represents the primary coordinating node of view v.

[0021] In step 101, all nodes propose a block in the current time period, determine the transactions carried by the block according to the block type and the transaction proof digest set, and send the proposal message generated by the proposed block to all nodes. Here, all nodes include the main coordinating node of the current view and multiple nodes, and the block type includes main chain blocks and transaction blocks. Step 101 corresponds to the proposal phase. In practice, the main coordinating node and each node (pi) propose a block in each time period sl. Each block includes a parent block link, time period, view number, block height, a batch of transactions carried by the block, verified quorum certificates, and quorum certificates for side blocks.

[0022] A block can be represented as [pl, sl, view, height, op, jqc, uqc], where pl represents the parent block link (i.e., the hash value of the parent block b' of b), sl represents the time period, view represents the view number, height represents the block height, height = b' .height + 1, op represents the payload, jqc represents the justified quorum certificate (can be written as justifiedQC), and uqc represents the quorum certificate of the side block (can be written as uncleQC). A block proposal can be represented as (PROPOSE, b).

[0023] Quorum Certificate (QC): A quorum certificate (QC) consists of 2f+1 VOTE votes for the same block b. It is usually instantiated by 2f+1 digital signatures or threshold signatures. Votes are divided into different types according to their signature fields. For a quorum certificate instance qc, type (qc) and block (qc) are used to represent the voting type of qc and the block corresponding to qc.

[0024] Block types include main chain (ml) blocks and transaction (tr) blocks. Additionally, if a block b has a non-empty uqc field, then block b has an uncle block, i.e., the block corresponding to the uqc. JustifiedQC is similar to genericQC used in HotStuff. Unlike HotStuff, where QCs used to submit blocks need to form a continuous height, justifiedQC in PICHU-DAG does not. If an ml block contains a non-empty uqc field, it is called an ml block carrying an uncleQC.

[0025] For each block b, rank(b) depends on b.view and b.height. This embodiment of the invention only concerns whether a block's rank is higher. The block ranks are compared as follows: first by view number, then by height. Alternatively, rank(qc) can be used to represent the rank of the block corresponding to qc.

[0026] Each node periodically submits proposal messages at regular intervals. Block 'b' in these proposal messages is an extension of the highQC block. Simultaneously, 'b' directly continues the block previously proposed by proposer(v). If 'b' carries QC, it's called an ml block; otherwise, it's a tr block. The block structure is as shown above. Nodes need to track their latest proposed ml block 'B'. ml .

[0027] In one embodiment, multiple nodes, acting as proposal nodes, construct blocks, including: If the node is the main coordinating node and the current time period is 1, the verified quorum certificate of the proposed block and the quorum certificate of the side block are set to the stop flag, the type of the block is determined to be the main chain block, and this block is the first main chain block; If the node is the main coordinating node and the consensus view change symbol is 0, and it receives the first number of new view messages for the current view, it sets the consensus view change symbol to 1, sets the highest quorum certificate of the proposed block to the highest quorum certificate contained in the new view message, sets the verified quorum certificate to the stop flag, sets the quorum certificate of the side block to the highest quorum certificate, and determines the type of the block as a main chain block. If the consensus view change symbol is 1 and the quorum certificate of the last voting main chain block has been received, set the verified quorum certificate of the proposed block as the quorum certificate of the last voting main chain block, set the quorum certificate of the side block as the stop flag, and determine the type of the block as the main chain block. Otherwise, increment the verified quorum certificate of the proposed block and the quorum certificate of the side block by 1 to determine that the blockchain type is a transaction block.

[0028] In this embodiment of the invention, each node can be represented as pi. If pi = Proposer(v) and the current time period current sl(csl) = 1, then jqc is set to a stop flag. uqc is the stop flag. The type of the block is determined to be a main chain block, and this block is the first main chain block.

[0029] When the master coordinating node proposer(v) produces a block, it needs to determine whether it is currently on the longest main chain (whether it has received NEW-VIEW messages from nf views of v) before proposing block b. b directly continues the block previously proposed by proposer(v). If b carries a QC (Quality Control Message), it is called an ml block; otherwise, it is a tr block. The master coordinating node needs to keep track of its latest ml block B. ml .

[0030] If pi = Proposer(v) and the consensus view change symbol fl = 0, and the first number nf new-view messages (represented as M) of the current view v are received, set fl to 1, set the highest quorum certificate highQC to the highest QC contained in M, and set jqc to When uQC is set to highQC, the extracted block is the first ml block proposed by the leader after the view change, called the ml block carrying uncleQC. This block is used to determine the current highest-ranking leader during the view change phase. Before this, the blocks proposed by the main coordinating node are tr blocks.

[0031] If fl = 1 and B has been received ml If the quorum certificate is qc, then set jqc to qc and uqc to qc. The extracted block is a ml block.

[0032] Otherwise (i.e., if the above conditions are not met), set jqc +1 and uqc +1, and extract the transaction block b. In this case, transaction block b directly continues the block previously extracted by the main coordinating node.

[0033] In one embodiment, determining the transactions carried in a block based on the block type and the transaction proof digest set includes: If the block type is a main chain block, the block payload is determined to be a set of locally stored transaction proof digests; If the block type is a transaction block, the block payload is determined to be a batch of transactions to be confirmed.

[0034] In step 102, each node, acting as a verification node, collects blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that generated the block or the main coordinating node of the current consensus view, updating the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected.

[0035] Step 102 corresponds to the voting stage. After receiving (PROPOSE, b) from pj, let t' represent b.sl. Then wait to receive the block proposed by Pj for any time period t'' ≤ t', perform logical judgment, execute the corresponding operation, and set B[j] to b.

[0036] In one embodiment, for each received block, a voting message is generated by combining the block type with a locally stored time-based voting status table, and then sent to the proposing node that generated the block or the main coordinating node of the current consensus view, including: For each received block, if the block is a transaction block, a view timeliness check and a historical correlation check are performed respectively. After both checks pass, a voting message for the transaction block is generated and the voting message is returned to the proposal node along the original path of the received block. If the block is the main chain block, after the view timeliness check, inheritance check and proof condition check are performed and all pass, a voting message for the main chain block is generated and sent to the main coordinating node of the current view and the next view. The proof conditions include the proof conditions for stable mode and the proof conditions for switching mode.

[0037] In the above embodiments, for the block received from node j, if the block is a transaction block, the view timeliness check requires that the view number corresponding to the period of the block is less than the current view number, and the historical relevance check requires that the block is a sub-block of the j-th element in the time-periodized voting status table; For the block received from node j, if the block is a main-chain block, the view timeliness check requires that the view number corresponding to the period of the block is less than the current view number, and node j is the main coordinator corresponding to the period of the block. The inheritance check requires that the block is a sub-block of the j-th element in the time-periodized voting status table, and the proof condition check requires that condition k or condition d is satisfied; condition k is that the consensus view change symbol is 0 and condition e is satisfied, condition e is that condition f or condition g is satisfied, condition f is that the verified quorum certificate of the block is a binary group including qc and M, M is a set containing a first quantity of new view messages for the current view, qc is the highest quorum certificate of the main-chain block included in M, condition g is that the period of the block is 1 and both the verified quorum certificate and the side-chain block quorum certificate of the block are stop flags; condition d is that the consensus view change symbol is 1, and the verified quorum certificate of the block is the quorum certificate of the last voted main-chain block, and the view number of the last voted main-chain block is the same as the current view Figure 1 consistent.

[0038] In the embodiments of the present invention, for a tr block, it is only necessary to verify whether b is a sub-block of the previous voted block. The first condition is (b is a tr block OR view(t’) < cview) AND (b is a sub-block of B[j]).

[0039] For an ml block, the node first needs to verify whether b.sl is equal to the local current period. If not, b is verified and voted as a tr block.

[0040] If b is an ml block and fl = 1, each node needs to verify whether b is an extension of the previous ml block, that is, whether b.jqc contains the QC of the previous ml block. If fl = 0, each node needs to verify whether b.uqc contains n - f NEW-VIEW messages (M) for view v, and the highest-ranked quorum certificate among them. After voting on the ml block, fl needs to be set to 1.

[0041] Condition f can be expressed as b.uqc = (qc, M), and condition g can be expressed as (b.sl = 1 and b.uqc = b.jqc = ), where M contains a first quantity n - f of NEW-VIEW messages for view v.

[0042] The condition d can be expressed as (fl = 1) AND (b.jqc is B) ml QC) AND (B ml .view = v).

[0043] Update the local storage time-based voting status table by setting B[j] to b.

[0044] In one embodiment, the voting message corresponding to the block includes a voting message identifier, the block, the element corresponding to the node's own number in the transaction proof digest set, a global quorum certificate, and a partial signature, wherein the partial signature is a partial signature of a tuple of the transaction block and the hash value of the transaction block; In this embodiment of the invention, when the block is a transaction block, the voting message can be represented as (VOTE, tr, trQCs [i], globalQC, Send to pj, where This is a partial signature of (tr, hash(b)). When the block is a main chain block, the voting message can be represented as (VOTE, ml, trQCs[i], globalQC, ...). ) .

[0045] In step 103, all nodes collaboratively perform a global confirmation and commit operation for the main chain block.

[0046] Step 103 corresponds to the locking and commit phase. In PICHU-DAG, the locking and commit rules only apply to ml blocks. For ml block b, the direct predecessor block b' is found using b.jqc, and the indirect predecessor block b'' is found using b'.jqc. The height and time period of these blocks do not need to be consecutive; as long as they are generated in the same view, they can be committed as two blocks. Figure 2 In the middle, received b 3,9 and b 3,10 Then you can submit block b. 3,8 ).

[0047] When submitting an ml block, for each quorum certificate stored in the block's op field, find the chain containing the corresponding tr block (a chain consisting of blocks connected by pl blocks before this block), and package all transactions contained in the unsubmitted tr blocks on this chain together. Similarly, process each quorum certificate stored in the block's op field. All packaged transactions are then included as transactions in the ml block.

[0048] When submitting a regular ml block, all preceding blocks (i.e., a chain linked by pl) must be submitted together. It's important to note that if the submitted ml block 'b' carries uqc, then all preceding blocks of 'b' within this view must be packaged together and submitted as a subsequent block of 'block(b.uqc)'. This method ensures secure aggregation with the main chain.

[0049] In one embodiment, all nodes collaboratively perform a global confirmation and commit operation on the main chain block, including: After each node votes on the main chain block, the last voted main chain block is set as the main chain block, and the consensus view change symbol is set to 0; The node parses the verified quorum certificate carried by the main chain block and performs two-level backtracking along the certificate chain to obtain the direct predecessor block and the indirect predecessor block; If the verified quorum certificate of the main chain block is not equal to the stop flag, set the global quorum certificate to the verified quorum certificate of the main chain block. If the view number of the main block, the view number of the direct predecessor block, and the view number of the indirect predecessor block are all equal, submit the indirect predecessor block and all its preceding blocks.

[0050] The node parses the verified quorum certificate carried by the main chain block and performs two-level backtracking along the certificate chain to obtain the direct predecessor block and the indirect predecessor block. The block corresponding to the verified quorum certificate of the main chain block is marked as the direct predecessor block, and the block corresponding to the verified quorum certificate of the direct predecessor block is marked as the indirect predecessor block.

[0051] In one embodiment, the method further includes: After all nodes receive the first number of valid votes for each block, they form a quorum certificate for each block. If the block corresponding to the quorum certificate of this block is a transaction block, and the level of the quorum certificate of this transaction block is greater than the level of the element corresponding to the node's own number in the locally stored transaction proof digest set, then set the element with the node's own number in the locally stored transaction proof digest set as the quorum certificate of this block. When a quorum certificate is received from the transaction proof digest set of voting messages from node j, if the level of the received quorum certificate is higher than the level of the element numbered j in the received transaction proof digest set, the element numbered j in the locally stored transaction proof digest set is updated to the transaction block. The above corresponds to the quorum certificate update stage. In this embodiment of the invention, when the current node i receives nf valid voting messages for a certain block during the quorum certificate update stage, it forms a quorum certificate qc for that block. If block(qc) is a tr block and rank(qc) > rank(trQCs[i]), set the locally stored trQCs[i] to qc; When qc is received from the trQCs field of a VOTE message from pj: if rank(qc) > rank(trQCs[j]), set the locally stored trQCs[j] to qc.

[0052] In one embodiment, the method further includes: At the end of the current time period, each node updates its current view number, sets the consensus view change symbol to 0, and sends a new view message to the main coordinating node of the updated current view. The new view message includes a new view message identifier, an element corresponding to the node's own number in the transaction proof digest set, and a global quorum certificate.

[0053] In this embodiment of the invention, at the end of the last time period t of cview, cview is set to view (t+1), fl is set to 0, and (NEW-VIEW, trQCs[i], globalQC) is sent to Proposer(cview).

[0054] This invention also proposes a blockchain consensus device that supports parallel proposals from multiple nodes. Its principle is similar to that of the blockchain consensus method that supports parallel proposals from multiple nodes, and will not be described in detail here.

[0055] Figure 3 This is a schematic diagram of the structure of a blockchain consensus device supporting multi-node parallel proposals in an embodiment of the present invention. The blockchain consensus device supporting multi-node parallel proposals in an embodiment of the present invention includes: The proposal module 301 is used to construct blocks as proposal nodes in the current time period of the current consensus view. The types of blocks include transaction blocks for confirming transaction sets and main chain blocks for confirming the main chain status. Each proposal node determines the payload of the block according to the type of each block and the set of transaction proof digests stored locally, and broadcasts the proposal message containing the block to all nodes. The voting module 302 is used by each node as a verification node to collect blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that produced the block or the main coordinating node of the current consensus view, and updates the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected. Submission module 303 is used by all nodes to collaboratively perform global confirmation and submission operations on the main chain blocks.

[0056] In one embodiment, the proposal module is used for: If the block type is a main chain block, the block payload is determined to be a set of locally stored transaction proof digests; If the block type is a transaction block, the block payload is determined to be a batch of transactions to be confirmed.

[0057] In one embodiment, the voting module is used for: For each received block, if the block is a transaction block, a view timeliness check and a historical correlation check are performed respectively. After both checks pass, a voting message for the transaction block is generated and the voting message is returned to the proposal node along the original path of the received block. If the block is the main chain block, after the view timeliness check, inheritance check and proof condition check are performed and all pass, a voting message for the main chain block is generated and sent to the main coordinating node of the current view and the next view. The proof conditions include the proof conditions for stable mode and the proof conditions for switching mode.

[0058] In one embodiment, the voting message corresponding to the block includes a voting message identifier, the block, the element corresponding to the node's own number in the transaction proof digest set, a global quorum certificate, and a partial signature, wherein the partial signature is a partial signature of a tuple of the transaction block and the hash value of the transaction block.

[0059] In one embodiment, the submission module is used to: After each node votes on the main chain block, the last voted main chain block is set as the main chain block, and the consensus view change symbol is set to 0; The node parses the verified quorum certificate carried by the main chain block and performs two-level backtracking along the certificate chain to obtain the direct predecessor block and the indirect predecessor block; If the verified quorum certificate of the main chain block is not equal to the null symbol, set the global quorum certificate to the verified quorum certificate of the main chain block. If the consensus view number of the main chain block, the consensus view number of the direct predecessor block, and the consensus view number of the indirect predecessor block are all equal, submit the indirect predecessor block and all its preceding blocks.

[0060] Figure 4 This is another schematic diagram of a blockchain consensus device supporting multi-node parallel proposals in an embodiment of the present invention. In one embodiment, the device further includes a certificate update module 401, used for: After all nodes receive the first number of valid votes for each block, they form a quorum certificate for each block. If the block corresponding to the quorum certificate of this block is a transaction block, and the level of the quorum certificate of this transaction block is greater than the level of the element corresponding to the node's own number in the locally stored transaction proof digest set, then set the element with the node's own number in the locally stored transaction proof digest set as the quorum certificate of this block. When a quorum certificate is received from the transaction proof digest set of voting messages from node j, if the level of the received quorum certificate is higher than the level of the element numbered j in the received transaction proof digest set, the element numbered j in the locally stored transaction proof digest set is updated to the transaction block.

[0061] In one embodiment, the apparatus further includes a view update module 402, configured to: At the end of the current time period, each node updates its current view number, sets the consensus view change symbol to 0, and sends a new view message to the main coordinating node of the updated current view. The new view message includes a new view message identifier, an element corresponding to the node's own number in the transaction proof digest set, and a global quorum certificate.

[0062] In summary, the method and apparatus proposed in this invention extend the traditional BFT protocol's single-node broadcast block proposal mode to a mode where all nodes synchronously participate in block construction and proposal broadcasting through multi-node parallel proposal design. This concentrates network bandwidth on carrying core data such as block proposals, reducing redundant bandwidth consumption in unrelated steps and achieving efficient utilization of bandwidth resources. By leveraging time-based parallel proposals and asynchronous collection barrier mechanisms, each node can synchronously initiate block proposals based on its local clock, advancing consensus without waiting for a pre-voting process. This overcomes the bottleneck of the "waiting for voting threshold" in traditional BFT protocols, significantly shortening the consensus cycle and improving overall execution efficiency. By differentiating the payload logic of main chain blocks and transaction blocks, block data adapts to different consensus requirements. Combined with the dynamic updates of the time-based voting status table, after deployment in the blockchain system, it can simultaneously improve overall system performance and transaction throughput, while reducing average transaction latency, achieving synergistic optimization of multiple core indicators. This solution is compatible with the architectural characteristics of permissioned blockchains and hybrid blockchains. It retains the fault tolerance and attack resistance of the BFT protocol, while enhancing the scalability of the system through a multi-node parallel mechanism. It can adapt to more types of distributed application scenarios and has broader promotional value.

[0063] This invention also provides a computer device. Figure 5 This is a schematic diagram of a computer device in an embodiment of the present invention. The computer device 500 includes a memory 510, a processor 520, and a computer program 530 stored in the memory 510 and executable on the processor 520. When the processor 520 executes the computer program 530, it implements the above-mentioned blockchain consensus method that supports multi-node parallel proposals.

[0064] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned blockchain consensus method supporting multi-node parallel proposals.

[0065] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned blockchain consensus method supporting multi-node parallel proposals.

[0066] 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 a completely hardware embodiment, a completely software embodiment, or an embodiment 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, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. 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 blockchain consensus method supporting parallel proposals from multiple nodes, characterized in that, Applied to blockchain systems consisting of multiple nodes, including: In the current time period of the current consensus view, multiple nodes, acting as proposal nodes, construct blocks respectively. The types of blocks include transaction blocks used to confirm transaction sets and main chain blocks used to confirm the main chain status. Each proposing node determines the payload of a block based on its type and the set of transaction proof digests stored locally, and broadcasts the proposal message containing that block to all nodes. Each node, acting as a verification node, collects blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that generated the block or the main coordinating node of the current consensus view, updating the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected. All nodes work together to perform a global confirmation and commit operation on the main chain blocks.

2. The method as described in claim 1, characterized in that, Each proposal node determines the payload of a block based on its block type and the set of transaction proof digests stored locally, including: If the block type is a main chain block, the block payload is determined to be a set of locally stored transaction proof digests; If the block type is a transaction block, the block payload is determined to be a batch of transactions to be confirmed.

3. The method as described in claim 1, characterized in that, For each received block, a voting message is generated by combining the block type with the locally stored time-based voting status table, and then sent to the proposing node that generated the block or the main coordinating node of the current consensus view, including: For each received block, if the block is a transaction block, a view timeliness check and a historical correlation check are performed respectively. After both checks pass, a voting message for the transaction block is generated and the voting message is returned to the proposal node along the original path of the received block. If the block is the main chain block, after the view timeliness check, inheritance check and proof condition check are performed and all pass, a voting message for the main chain block is generated and sent to the main coordinating node of the current view and the next view. The proof conditions include the proof conditions for stable mode and the proof conditions for switching mode.

4. The method as described in claim 1, characterized in that, The voting message corresponding to the block includes a voting message identifier, the block, the element corresponding to the node's own number in the transaction proof digest set, the global quorum certificate, and a partial signature, wherein the partial signature is a partial signature of the tuple of the transaction block and the hash value of the transaction block.

5. The method as described in claim 1, characterized in that, All nodes collaborate to perform a global confirmation and commit operation on the main chain block, including: After each node votes on the main chain block, it sets the last voted main chain block as the main chain block and sets the consensus view change symbol to 0. The node parses the verified quorum certificate carried by the main chain block and performs two-level backtracking along the certificate chain to obtain the direct predecessor block and the indirect predecessor block; If the verified quorum certificate of the main chain block is not equal to the null symbol, set the global quorum certificate to the verified quorum certificate of the main chain block. If the consensus view number of the main chain block, the consensus view number of the direct predecessor block, and the consensus view number of the indirect predecessor block are all equal, submit the indirect predecessor block and all its preceding blocks.

6. The method as described in claim 1, characterized in that, Also includes: After all nodes receive the first number of valid votes for each block, they form a quorum certificate for each block. If the block corresponding to the quorum certificate of this block is a transaction block, and the level of the quorum certificate of this transaction block is greater than the level of the element corresponding to the node's own number in the locally stored transaction proof digest set, then set the element with the node's own number in the locally stored transaction proof digest set as the quorum certificate of this block. When a quorum certificate is received from the transaction proof digest set of voting messages from node j, if the level of the received quorum certificate is higher than the level of the element numbered j in the received transaction proof digest set, the element numbered j in the locally stored transaction proof digest set is updated to the transaction block.

7. The method as described in claim 1, characterized in that, Also includes: At the end of the current time period, each node updates its current view number, sets the consensus view change symbol to 0, and sends a new view message to the main coordinating node of the updated current view. The new view message includes a new view message identifier, an element corresponding to the node's own number in the transaction proof digest set, and a global quorum certificate.

8. A blockchain consensus device supporting parallel proposals from multiple nodes, characterized in that, The device, applicable to a blockchain system consisting of multiple nodes, includes: The proposal module is used to construct blocks by multiple nodes as proposal nodes in the current time period of the current consensus view. The types of blocks include transaction blocks for confirming transaction sets and main chain blocks for confirming the main chain status. Each proposal node determines the payload of the block according to the type of each block and the set of transaction proof digests stored locally, and broadcasts the proposal message containing the block to all nodes. The voting module is used by each node as a validator to collect blocks from all proposal messages that satisfy the asynchronous collection barrier. For each received block, it generates a voting message by combining the block type with the locally stored time-based voting status table, and sends it to the proposing node that produced the block or the main coordinating node of the current consensus view, and updates the locally stored time-based voting status table. The asynchronous collection barrier is to synchronously wait after receiving a valid proposal message until a first number of valid proposal messages in the current time period and blocks from all proposal messages sent by the valid proposal message sending node in all previous time periods are collected. The submission module is used by all nodes to collaboratively perform global confirmation and submission operations on the main chain blocks.

9. 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 computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images