Single-master time block consensus method and device

Abstract

This invention discloses a single-master timed block production consensus method and apparatus. The method includes: the leader node of the current view proposes a block in the current time period and determines the type of the block; the proposed block proposal is sent to all replica nodes; the block types include main chain blocks and transaction blocks; upon receiving a valid block proposal, the replica nodes wait until they receive blocks from all block proposals proposed by the leader node in all time periods in the current view; they then vote on each block based on its type, generating a voting message for each block and sending it to the leader node; the replica nodes lock and commit blocks of the main chain block type; after receiving a first number of valid voting messages, the leader node generates a quorum certificate for the last voted main chain block; and the replica nodes perform view changes based on their local highest quorum certificate. This invention can improve consensus efficiency.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and cloud service technology, and in particular to a single-master timed block generation consensus method and apparatus. 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] Byzantine fault-tolerant state machine replication (BFT) is a protocol that tolerates arbitrary failures and resists malicious attacks. BFT has long been considered a crucial component of a building block's foundation. It is a recognized model for permissioned blockchains and is increasingly being adopted by hybrid blockchains. The most resource-intensive step in a BFT protocol is the block proposal—the process by which the protocol leader sends a block proposal to all replicas. This is natural because block proposals are typically much larger than other types of messages, such as voting messages which usually only carry hashes and / or digital signatures. Since block proposals are necessary, communication steps other than block proposals appear to waste network bandwidth, such as collecting votes from replicas. This stems primarily from the fact that these communication steps are only used to reach consensus on block ordering, rather than utilizing network bandwidth to improve throughput and scalability. Such communication steps are called bandwidth-independent steps. However, almost all existing protocols involve some bandwidth-wasting steps. Typical examples include PBFT and HotStuff. In these bandwidth-wasting steps, replicas or the leader must wait to collect enough votes (typically the votes of 2 / 3 of the nodes in the system) before proceeding to the next step. Therefore, network bandwidth is not being fully utilized to achieve higher throughput and scalability. Summary of the Invention

[0004] This invention provides a single-master timed block production consensus method that can fully utilize the master node's network bandwidth 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 multi-dimensional performance, and has broad application prospects, including: The leader node of the current view proposes a block in the current time period, determines the type of the block, and sends the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. When a replica node receives a valid block proposal, it waits until it receives a block from all block proposals made by the leader node in all time periods in the current view. Then, it votes on each block based on its type, generates a voting message for each block, and sends it to the leader node. Replica nodes lock and commit blocks of type main chain block; After receiving the first number of valid votes, the leader node generates a quorum certificate for the last voting main chain block. The replica node changes its view based on the highest quorum certificate in its local system.

[0005] This invention also provides a single-master timed block production consensus device, which can fully utilize the master node's network bandwidth based on network latency to improve consensus efficiency. When deployed in distributed systems such as blockchain, it can significantly improve system efficiency, throughput, average transaction latency, and other multi-dimensional performance, and has broad application prospects, including: The proposal module is used by the leader node of the current view to propose a block in the current time period, determine the type of the block, and send the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. The voting module is used by replica nodes to wait until they receive a block proposal from the leader node in all time periods when they receive a block proposal in the current view. Then, they vote on each block based on its type, generate a voting message for each block, and send it to the leader node. The commit module is used by replica nodes to lock and commit blocks of type main chain block; The certificate update module is used by the leader node to generate a quorum certificate for the last voting main chain block after receiving the first number of valid vote messages; The view change module is used by replica nodes to change the view based on the highest quorum certificate in the local system.

[0006] 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 above-described single-master timed block production consensus method.

[0007] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described single-master timed block production consensus method.

[0008] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described single-master timed block production consensus method.

[0009] In this embodiment of the invention, the design of "single-master timed block production + typed block proposal" avoids the redundant consumption of "voting collection-type bandwidth-unrelated steps" in traditional BFT protocols, fully utilizing the master node's network bandwidth and solving the problem that bandwidth resources in existing protocols are not focused on throughput improvement. The mechanism of "local clock-based timed proposal + no need to wait for pre-voting" breaks through the efficiency bottleneck of "requiring 2 / 3 of the nodes to vote before the process can proceed" in protocols such as PBFT and HotStuff, significantly shortening the consensus cycle and directly improving consensus execution speed. When deployed in distributed systems such as blockchains, it can simultaneously optimize core indicators such as overall system efficiency, transaction throughput, and average transaction latency, achieving multi-dimensional performance synergy improvement compared to traditional BFT solutions. Supporting block type division of "main chain block + transaction block," it adapts to the core model requirements of permissioned chains and is also compatible with the architectural characteristics of hybrid blockchains, possessing broad application scenarios and promotional value in distributed systems. Attached Figure Description

[0010] 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 the single-master timed block production consensus method in an embodiment of the present invention; Figure 2 This is a schematic diagram of the message flow for single-master timed block production consensus in an embodiment of the present invention; Figure 3 This is a flowchart illustrating how a replica node locks and commits a block of type main chain block in an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of the single-master timed block production consensus device 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

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

[0012] In this embodiment of the invention, the leader node setting of the single-master timed block production consensus method PICHU-HS is similar to that of PBFT and HotStuff. The protocol is view-based, and each view v has a unique pre-set leader node leader(v). All correct replica nodes can obtain the identity of the leader node of view v by calculating leader(v). The leader node is responsible for proposing blocks, and all replica nodes act as voters for the blocks.

[0013] The main advantages of PICHU-HS compared with other BFT protocols are: (1) at any stage of the protocol (including the regular stage and view change), the leader node proposes blocks in a timed manner without waiting for the collection of votes; (2) PICHU-HS is provably secure; (3) PICHU-HS achieves optimal linear communication complexity.

[0014] Specifically, regarding data types: For blocks receiving different numbers of votes, this embodiment of the invention innovatively designs a block data structure and provides corresponding new rules for block proposal, verification, and submission. Regarding protocol details: (1) During the block proposal phase, to avoid voting waiting time, a new block structure and block types (including mc blocks (carrying votes) and light blocks (not carrying votes) were designed so that the leader node could produce blocks based on its local clock. The collection of votes affects the block type, but does not affect the block production behavior (i.e., a block can be produced even if no votes for the previous block have been collected). (2) During the block voting phase, new validity verification rules were designed for different types of blocks, allowing replicas to safely vote on blocks that do not carry votes; (3) New block submission rules were proposed to prevent blocks without voting from having any security impact on consensus; (4) Based on maintaining the timed block generation property of view replacement, a new view replacement method is proposed using MC blocks to ensure that the leader can also generate new blocks at regular intervals even if it has not received enough view replacement messages, and can eventually converge on the longest main chain, and can prove to all nodes that a safe view replacement has been completed.

[0015] The following is a detailed introduction to PICHU-HS.

[0016] Figure 1 The flowchart of the single-master timed block production consensus method in this embodiment of the invention includes: Step 101: The leader node of the current view proposes a block in the current time period, determines the type of the block, and sends the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. Step 102: When a replica node receives a valid block proposal, it waits until it receives a block from all block proposals made by the leader node in all time periods in the current view. Then, it votes on each block based on the type of each block, generates a voting message for each block, and sends it to the leader node. Step 103: The replica nodes lock and commit the blocks of type main chain block; Step 104: After receiving the first number of valid vote messages, the leader node generates a quorum certificate for the last voting main chain block. Step 105: The replica node performs a view change based on the local highest quorum certificate.

[0017] PICHU-HS employs a block proposal paradigm based on a local timer. At the start of each time period t, the leader node proposes a block proposal and sends it to all replica nodes (the block type in the proposal is determined by locally received votes). Replica nodes receive a valid block proposal where block b.slot ≤ t, vote on b based on its type, and send it to the leader node. At the beginning of time period t, any replica node starts a timer Δ. After the timer expires, time period t+1 begins. Each step is described in detail below.

[0018] In this embodiment of the invention, 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.

[0019] Before executing the method proposed in this embodiment of the invention for the first time, the time slot can be initialized to the current time slot cslot=0, the view number view can be initialized to the current view number cview=0, and the highest legal personnel certificate highQC and the locked legal personnel certificate lockedQC can be initialized as terminators. The last voting block B is the terminator; the last voting main chain block B... mc for The security view change flag is 0. leader(v) represents the leader node of view v.

[0020] In step 101, the leader node of the current view proposes a block in the current time period, determines the type of the block, and sends the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. Step 101 corresponds to the proposal phase. In one embodiment, each block includes a parent block link, time period, view number, block height, a batch of transactions carried by the block, a verified quorum certificate, and a quorum certificate for the side block.

[0021] A block can be represented as [pl, slot, view, height, op, jqc, uqc], where pl represents the parent block link (i.e., the hash value of the parent block b' of b), slot represents the time period, view represents the view number, height represents the block height, height = b' .height + 1, op represents a batch of transactions carried by the block, jqc represents the verified 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).

[0022] Quorum Certificate (QC): A quorum certificate 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.

[0023] Block types include main chain (MC) blocks and transaction (Light) blocks. Additionally, if a block `b` has a non-empty `uqc` field, then block `b` has an `uncle` block, which is 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-HS does not require this. If an MC block contains a non-empty `uqc` field, it is called an MC block carrying an `uncleQC`.

[0024] 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 block(qc), i.e., the rank of the block corresponding to qc.

[0025] The leader node periodically proposes block proposals at each time period. Block 'b' in the block proposal is an extension of the highQC block. Simultaneously, 'b' directly continues the block previously proposed by leader(v). If 'b' carries QC, it is called an MC block; otherwise, it is a light block. The block structure is as shown above. The leader needs to track the latest main chain block 'B' that it has proposed. mc .

[0026] Figure 2 This is a schematic diagram of the message flow for single-master timed block production consensus in an embodiment of the present invention. See [link / reference]. Figure 2 B1 to B6 are blocks, and P1 to P4 are nodes. Yellow represents MC blocks, and green represents light blocks. Figure 2 The message flow for each stage is given.

[0027] See Figure 2 In one embodiment, the leader node of the current view proposes a block in the current time period and determines the type of the block, including: If the current time period is 1, set the verified quorum certificate and the quorum certificate of the side block as the terminator, determine the type of the block as the main chain block, and this block is the first main chain block; If the security view change flag is 0 and a first number of new view messages for the current view are received, set the security view change flag to 1, set the highest quorum certificate to the highest quorum certificate contained in the new view message, set the verified quorum certificate to the terminator, set the quorum certificate of the side block to the highest quorum certificate, and determine the type of the block as the main chain block. If the security view change flag is 1 and the quorum certificate for the last voting main chain block has been received, set the verified quorum certificate as the quorum certificate for the last voting main chain block, and set the quorum certificate for the side chain block as the terminator. Otherwise, set the verified quorum certificate and the quorum certificate of the side block as the terminator, and determine the type of the block as a transaction block.

[0028] In this embodiment of the invention, if the current time slot (cslot) = 1, then jqc is set as the terminator. uqc is the terminator. The type of the block is determined to be a main chain block, and this block is the first main chain block.

[0029] If the security view change flag is 0 and the first number of new view messages (represented as M) of the current view v are received, set the flag to 1, set the highest quorum certificate (highQC) to the highest quorum certificate contained in M, and set jqc to... Set uqc to highQC, and the extracted block is the mc block carrying uncleQC.

[0030] If flag = 1 and B has been received mc If the quorum certificate is an instance of qc, then set jqc to qc and uqc to qc. The extracted block is the mc block.

[0031] Otherwise (i.e., if the above conditions are not met), set jqc to uqc is The extracted block is the light block.

[0032] In step 102, when a replica node receives a valid block proposal, it waits until it receives a block from all block proposals made by the leader node in all time periods in the current view. Then, it votes on each block based on the type of each block, generates a voting message for each block, and sends it to the leader node.

[0033] Step 102 corresponds to the voting stage. In one embodiment, voting is conducted on each block based on its type, generating a voting message for each block, including: For each block, if the block meets one of the following three main conditions, the last voting block is set as that block, and a voting message is generated for each block: The first primary condition is that three sub-conditions of type I are met simultaneously. The first sub-condition is that the block is a transaction block, the second sub-condition is that the current time period of the block is not 1, and the third sub-condition is that the block is a sub-block of the last voting block or the current time period is the first time period of the current view. The second main condition is to simultaneously satisfy three sub-conditions of type II. The first sub-condition of type II is that the block is a main chain block. The second sub-condition of type II is that the security view change flag is 0. The third sub-condition of type II is to satisfy one of two branch conditions. The first branch condition is that the quorum certificate of the side block of the block is not a terminator, and the level of the quorum certificate of the side block of the block is greater than or equal to the level of the lock quorum certificate. The second branch condition is that the time period of the block is 1. The third main condition is that six sub-conditions of type 3 must be met simultaneously. The first sub-condition is that the block is a main chain block; the second sub-condition is that the security view change flag is 1; the third sub-condition is that the verified quorum certificate of the block is not a terminator; the fourth sub-condition is that the block is a sub-block of the final voting block; the fifth sub-condition is that the block corresponding to the verified quorum certificate of the block is the final voting main chain block; and the sixth sub-condition is that the view number corresponding to the final voting main chain block is equal to the current view number.

[0034] In this embodiment of the invention, the above three conditions can be expressed as: (b is a light block) AND (b.slot ≠ 1) AND (b is a sub-block of B OR the current time period t is the first time period of the current view v).

[0035] (b is mc block) AND (flag=0) AND ((b.uqc≠⊥ AND rank(b.uqc)≥rank(lockedQC)) OR (b.slot=1)).

[0036] (b is a block in MC) AND (flag=1) AND (b.jqc≠⊥) AND (b is a child block of B) AND (block(b.jqc)=B) mc AND (B) mc .view=v).

[0037] In one embodiment, the voting message for each block includes a voting message identifier, the block's hash value, and a partial signature of the hash value.

[0038] A voting message can be represented as (VOTE, hash(b)). ), where VOTE is the voting message identifier, It is a partial signature of hash(b).

[0039] In one embodiment, after generating the voting message for each block, the method further includes: If this block is the main chain block, set the last voting main chain block as this block and set the security view change flag to 1.

[0040] In this embodiment of the invention, if b is an mc block, set B mc Let b be the value of the flag, and flag be 1.

[0041] In step 103, the replica node locks and commits the block of type main chain block.

[0042] Figure 3 This is a flowchart illustrating how a replica node locks and commits a block of type main chain block in an embodiment of the present invention. In one embodiment, locking and committing a block of type main chain block by a replica node includes: Step 301: After the replica node votes on the main chain block, it sets the local highest quorum certificate as the verified quorum certificate of the main chain block. Step 302: Mark the block corresponding to the verified quorum certificate of the main chain block as the first block; Step 303: Mark the block corresponding to the verified quorum certificate of the first block as the second block; Step 304: Mark the block corresponding to the verified quorum certificate of the second block as the third block; Step 305: If the view number of the second block is equal to the current view number, set the locked quorum certificate to the verified quorum certificate of the first block. Step 306: If the view number of the third block is equal to the current view number, commit the third block and all preceding blocks of the third block.

[0043] In this embodiment of the invention, the locking and commit rules are similar to those of HotStuff, with the main difference being that HotStuff determines the locking and commit rules for any block and requires the locking and committing blocks to be of contiguous height. In PICHU-HS, the locking and commit rules only apply to mc blocks. For mc block b, b' is found using b.jqc, b'.jqc finds b'', and b''.jqc finds b. 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 locked according to two blocks. Figure 2 Upon receiving b5 and b6, lockedQC can be set as the quorum certificate for b4, along with a three-block commit. Figure 2 In the process, upon receiving b4, b5, and b6, the rule for b3 can be submitted to lock and commit. Therefore, let b' represent block (b.jqc), b'' represent block (b'.jqc), and b... Represents block (b''.jqc). If b''.view = v, set lockedQC to b'.jqc; if b .view = v, Submit b and b All preceding blocks.

[0044] When submitting a regular MC block, all preceding blocks (i.e., a chain linked by PL) of this block must be submitted together. It's important to note that if the submitted MC 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 allows for secure aggregation with the main chain.

[0045] In step 104, after receiving the first number of valid vote messages, the leader node generates a quorum certificate for the last voting main chain block.

[0046] In this embodiment of the invention, if the current node pi = leader(v), upon receiving a first number of valid vote messages nf, where a valid vote message can be represented as (VOTE, hash(B)) mc ), ), for B mc A quorum certificate is generated.

[0047] In step 105, the replica node performs a view change based on the local highest quorum certificate.

[0048] In one embodiment, the replica node performs view changes based on the local highest quorum certificate, including: If a replica node times out in the current view, it increments the current view number by 1, sets the security view change flag to 0, and sends a new view message to the leader node of the next view. The new view message includes a new view message identifier, the local highest quorum certificate, and the view number of the next view.

[0049] In this embodiment of the invention, if v times out, cview is set to cview + 1, flag is 0, and (NEW-VIEW, highQC, v+ 1) is sent to leader (v+ 1).

[0050] This invention also proposes a single-master timed block production consensus device, the principle of which is similar to the single-master timed block production consensus method, and will not be described in detail here.

[0051] Figure 4 This is a schematic diagram of the structure of a single-master timed block production consensus device in an embodiment of the present invention. The single-master timed block production consensus device in this embodiment of the present invention includes: The proposal module 401 is used by the leader node of the current view to propose a block in the current time period, determine the type of the block, and send the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. The voting module 402 is used by replica nodes to wait until they receive a block proposal from the leader node in all time periods when they receive a block proposal in the current view. Then, it votes on each block based on the type of each block, generates a voting message for each block, and sends it to the leader node. Submission module 403 is used by replica nodes to lock and commit blocks of type main chain block; The certificate update module 404 is used by the leader node to generate a quorum certificate for the last voting main chain block after receiving the first number of valid vote messages; The view change module 405 is used by replica nodes to perform view changes based on the local highest quorum certificate.

[0052] In one embodiment, each block includes a parent block link, time period, view number, block height, a batch of transactions carried by the block, a verified quorum certificate, and a quorum certificate for the side block.

[0053] In one embodiment, the proposal module is used for: If the current time period is 1, set the verified quorum certificate and the quorum certificate of the side block as the terminator, determine the type of the block as the main chain block, and this block is the first main chain block; If the security view change flag is 0 and a first number of new view messages for the current view are received, set the security view change flag to 1, set the highest quorum certificate to the highest quorum certificate contained in the new view message, set the verified quorum certificate to the terminator, set the quorum certificate of the side block to the highest quorum certificate, and determine the type of the block as the main chain block. If the security view change flag is 1 and the quorum certificate for the last voting main chain block has been received, set the verified quorum certificate as the quorum certificate for the last voting main chain block, and set the quorum certificate for the side chain block as the terminator. Otherwise, set the verified quorum certificate and the quorum certificate of the side block as the terminator, and determine the type of the block as a transaction block.

[0054] In one embodiment, the voting module is used for: For each block, if the block meets one of the following three main conditions, the last voting block is set as that block, and a voting message is generated for each block: The first primary condition is that three sub-conditions of type I are met simultaneously. The first sub-condition is that the block is a transaction block, the second sub-condition is that the current time period of the block is not 1, and the third sub-condition is that the block is a sub-block of the last voting block or the current time period is the first time period of the current view. The second main condition is to simultaneously satisfy three sub-conditions of type II. The first sub-condition of type II is that the block is a main chain block. The second sub-condition of type II is that the security view change flag is 0. The third sub-condition of type II is to satisfy one of two branch conditions. The first branch condition is that the quorum certificate of the side block of the block is not a terminator, and the level of the quorum certificate of the side block of the block is greater than or equal to the level of the lock quorum certificate. The second branch condition is that the time period of the block is 1. The third main condition is that six sub-conditions of type 3 must be met simultaneously. The first sub-condition is that the block is a main chain block; the second sub-condition is that the security view change flag is 1; the third sub-condition is that the verified quorum certificate of the block is not a terminator; the fourth sub-condition is that the block is a sub-block of the final voting block; the fifth sub-condition is that the block corresponding to the verified quorum certificate of the block is the final voting main chain block; and the sixth sub-condition is that the view number corresponding to the final voting main chain block is equal to the current view number.

[0055] In one embodiment, the voting message for each block includes a voting message identifier, the block's hash value, and a partial signature of the hash value.

[0056] In one embodiment, the voting module is used for: After generating the voting message for each block, if the block is the main chain block, set the last voting main chain block as that block and set the security view change flag to 1.

[0057] In one embodiment, the submission module is configured to: After a replica node votes on a main chain block, it sets the highest quorum certificate in its local branch to the verified quorum certificate of the main chain block. Mark the block corresponding to the verified quorum certificate of the main chain block as the first block; Mark the block corresponding to the verified quorum certificate in the first block as the second block; Mark the block corresponding to the verified quorum certificate in the second block as the third block; If the view number of the second block is equal to the current view number, the quorum certificate will be locked and set to the verified quorum certificate of the first block. If the view number of the third block is equal to the current view number, commit the third block and all its preceding blocks.

[0058] In one embodiment, the view change module is used to: If a replica node times out in the current view, it increments the current view number by 1, sets the security view change flag to 0, and sends a new view message to the leader node of the next view. The new view message includes a new view message identifier, the local highest quorum certificate, and the view number of the next view.

[0059] In summary, the method and apparatus proposed in this invention, through the design of "single-master timed block production + typed block proposal," avoid the redundant consumption of "voting collection-type bandwidth-unrelated steps" in traditional BFT protocols, fully utilizing the master node's network bandwidth and solving the problem that bandwidth resources in existing protocols are not focused on throughput improvement. The mechanism of "local clock-based timed proposal + no need to wait for pre-voting" breaks through the efficiency bottleneck of "requiring 2 / 3 of the nodes to vote before the process can proceed" in protocols such as PBFT and HotStuff, significantly shortening the consensus cycle and directly improving consensus execution speed. When deployed in distributed systems such as blockchain, it can simultaneously optimize core indicators such as overall system efficiency, transaction throughput, and average transaction latency, achieving multi-dimensional performance synergy improvement compared to traditional BFT solutions. Supporting block type division of "main chain block + transaction block," it adapts to the core model requirements of permissioned chains and is compatible with the architectural characteristics of hybrid blockchains, possessing broad application scenarios and promotional value in distributed systems.

[0060] 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-described single-master timed block production consensus method.

[0061] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described single-master timed block production consensus method.

[0062] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described single-master timed block production consensus method.

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

[0064] 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. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

[0067] 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 single-master timed block production consensus method, characterized in that, Applied to blockchain systems, including: The leader node of the current view proposes a block in the current time period, determines the type of the block, and sends the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. When a replica node receives a valid block proposal, it waits until it receives a block from all block proposals made by the leader node in all time periods in the current view. Then, it votes on each block based on its type, generates a voting message for each block, and sends it to the leader node. Replica nodes lock and commit blocks of type main chain block; After receiving the first number of valid votes, the leader node generates a quorum certificate for the last voting main chain block. The replica node changes its view based on the highest quorum certificate in its local system.

2. The method as described in claim 1, characterized in that, 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.

3. The method as described in claim 1, characterized in that, The leader node of the current view proposes a block in the current time period and determines the type of the block, including: If the current time period is 1, set the verified quorum certificate and the quorum certificate of the side block as the terminator, determine the type of the block as the main chain block, and this block is the first main chain block; If the security view change flag is 0 and a first number of new view messages for the current view are received, set the security view change flag to 1, set the highest quorum certificate to the highest quorum certificate contained in the new view message, set the verified quorum certificate to the terminator, set the quorum certificate of the side block to the highest quorum certificate, and determine the type of the block as the main chain block. If the security view change flag is 1 and the quorum certificate for the last voting main chain block has been received, set the verified quorum certificate as the quorum certificate for the last voting main chain block, and set the quorum certificate for the side chain block as the terminator. Otherwise, set the verified quorum certificate and the quorum certificate of the side block as the terminator, and determine the type of the block as a transaction block.

4. The method as described in claim 1, characterized in that, Each block is voted on based on its type, generating a voting message for each block, including: For each block, if the block meets one of the following three main conditions, the last voting block is set as that block, and a voting message is generated for each block: The first primary condition is that three sub-conditions of type I are met simultaneously. The first sub-condition is that the block is a transaction block, the second sub-condition is that the current time period of the block is not 1, and the third sub-condition is that the block is a sub-block of the last voting block or the current time period is the first time period of the current view. The second main condition is to simultaneously satisfy three sub-conditions of type II. The first sub-condition of type II is that the block is a main chain block. The second sub-condition of type II is that the security view change flag is 0. The third sub-condition of type II is to satisfy one of two branch conditions. The first branch condition is that the quorum certificate of the side block of the block is not a terminator, and the level of the quorum certificate of the side block of the block is greater than or equal to the level of the lock quorum certificate. The second branch condition is that the time period of the block is 1. The third main condition is that six sub-conditions of type 3 must be met simultaneously. The first sub-condition is that the block is a main chain block; the second sub-condition is that the security view change flag is 1; the third sub-condition is that the verified quorum certificate of the block is not a terminator; the fourth sub-condition is that the block is a sub-block of the final voting block; the fifth sub-condition is that the block corresponding to the verified quorum certificate of the block is the final voting main chain block; and the sixth sub-condition is that the view number corresponding to the final voting main chain block is equal to the current view number.

5. The method as described in claim 1, characterized in that, The voting message for each block includes a voting message identifier, the block's hash value, and a partial signature of the hash value.

6. The method as described in claim 1, characterized in that, After generating the voting message for each block, the following is also included: If this block is the main chain block, set the last voting main chain block as this block and set the security view change flag to 1.

7. The method as described in claim 1, characterized in that, Replica nodes lock and commit blocks of type main chain block, including: After a replica node votes on a main chain block, it sets the highest quorum certificate in its local branch to the verified quorum certificate of the main chain block. Mark the block corresponding to the verified quorum certificate of the main chain block as the first block; Mark the block corresponding to the verified quorum certificate in the first block as the second block; Mark the block corresponding to the verified quorum certificate in the second block as the third block; If the view number of the second block is equal to the current view number, the quorum certificate will be locked and set to the verified quorum certificate of the first block. If the view number of the third block is equal to the current view number, commit the third block and all its preceding blocks.

8. The method as described in claim 1, characterized in that, The replica node performs view changes based on the local highest quorum certificate, including: If a replica node times out in the current view, it increments the current view number by 1, sets the security view change flag to 0, and sends a new view message to the leader node of the next view. The new view message includes a new view message identifier, the local highest quorum certificate, and the view number of the next view.

9. A single-master timed block production consensus device, characterized in that, The device, used in a blockchain system, includes: The proposal module is used by the leader node of the current view to propose a block in the current time period, determine the type of the block, and send the block proposal generated by the proposed block to all replica nodes. The types of blocks include main chain blocks and transaction blocks. The voting module is used by replica nodes to wait until they receive a block proposal from the leader node in all time periods when they receive a block proposal in the current view. Then, they vote on each block based on its type, generate a voting message for each block, and send it to the leader node. The commit module is used by replica nodes to lock and commit blocks of type main chain block; The certificate update module is used by the leader node to generate a quorum certificate for the last voting main chain block after receiving the first number of valid vote messages; The view change module is used by replica nodes to change the view based on the highest quorum certificate in the local system.

10. 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 8.

11. 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 8.

12. 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 8.

Images