A consensus method based on slicing

Abstract

The present invention discloses a consensus method based on slicing, in which the transaction blocks in each round of consensus proposals are sliced and proposals containing different slices are sent to each node in the blockchain system; after receiving the slices, each node restores the original transaction block information through three-stage communication collaboration; the message of the recovery process is piggybacked by the consensus message, and the recovery process occurs naturally in the consensus process without generating additional communication rounds; the method relies on a semi-synchronous network model to ensure activity; in a blockchain system with a total number of nodes N, the number of Byzantine nodes can be tolerated #imgabs0#The present invention is based on a slicing-based pipeline consensus method, which reduces the communication load of the leader node broadcasting proposals through slicing, balances the bandwidth consumption of the entire network, and improves the performance and scalability of the blockchain system under low-bandwidth conditions; at the same time, the pipeline design further improves the consensus efficiency.

Description

Technical Field

[0001] The present invention relates to the fields of state machine replication, Byzantine fault tolerance, blockchain technology, and consensus algorithm technology, and in particular to a consensus method based on slicing. Background Art

[0002] State Machine Replication (SMR) ensures data consistency in distributed systems. Since blockchain came into the public eye, a series of new Byzantine Fault Tolerant (BFT) SMR protocols have been designed to improve the efficiency and scalability of the system.

[0003] Due to the frequent communication steps in BFT protocols, bandwidth is a critical resource in blockchain systems. On the one hand, communication overhead increases with the number of nodes in a blockchain system. However, due to limited available bandwidth, this overhead eventually reaches a bottleneck. On the other hand, in specific application scenarios, blockchain systems face challenges with poor network conditions and low available bandwidth. For example, when blockchain is applied to drones, the communication method differs from that in ordinary scenarios, typically providing only minimal bandwidth and being affected by magnetic fields and electric currents. In these situations, even small-scale systems are more likely to reach bandwidth bottlenecks.

[0004] BFT protocols are subject to single-node bottlenecks, especially those based on leader nodes. In each round, the leader node generates a certificate (QC) using a list of secp256k1 signatures from other nodes and broadcasts it along with the new block. Other nodes only need to vote for the leader node. Obviously, the leader node has an O(N) communication overhead, which is much higher than that of other nodes. Therefore, as the system scales or available bandwidth decreases, the leader node will reach bandwidth limits earlier than other nodes, becoming a bottleneck. Summary of the Invention

[0005] The purpose of the present invention is to address the shortcomings of traditional consensus algorithms in terms of performance and scalability being limited by single-node bottlenecks, and to provide a slicing-based consensus method. This method reduces the communication load of the leader node broadcasting proposals by slicing transaction blocks using erasure codes, balances the bandwidth consumption of the entire network, and improves the performance and scalability of the blockchain system under low-bandwidth conditions. Furthermore, a slicing-based pipeline consensus method is proposed, which further improves the consensus efficiency through pipeline design.

[0006] The object of the present invention is achieved through the following technical solutions:

[0007] On the one hand, a consensus method based on slicing is provided, in which the transaction blocks in each round of consensus proposal are sliced, and proposals containing different slices are sent to each node in the blockchain system; after receiving the slices, each node recovers the information of the original transaction block through communication collaboration; the message of the recovery process is piggybacked by the consensus message, and the recovery process occurs naturally in the consensus process without generating additional communication rounds; this method relies on a semi-synchronous network model to ensure activity; in a blockchain system with a total number of nodes N, it can tolerate the number of Byzantine nodes. The consensus rounds of this method are marked by a monotonically increasing i. Each consensus round includes the following steps:

[0008] (1) Preparation phase: When the leader node L in round i i When the NEWVIEW messages of round i-1 reaching the first threshold are collected, L i Package NEWVIEW into certificate QC, and take out batchsize transactions from the local transaction pool and package them into block B of the current round. i , and calculate the block's hash BHash i ; Leader node L i The encoding function of B using the slicing method i Encode and obtain a slice set S containing N slices; the leader node L i Generate a proof for each slice in the slice set S to form a proof set P; the leader node L i Generate proposal collection Leader node L i Send a proposal PROPOSAL to node k k ∈Proposals;

[0009] Any node k waits until it receives PROPOSAL k When verifying p k And QC, if the verification passes, the slice s is stored k , broadcast the received slice and its proof echo<s k ,p k > and send it to the leader node L u Send vote prepareVote; when other nodes receive the slice and its proof echo from node k k ,p k >, verify p k If the verification is successful, store s k ;

[0010] (2) Pre-commit phase: When the leader node L i When the first threshold number of prepareVote votes is received, Li Package prepareVote into certificate QC and broadcast PRECOMMIT <QC>;

[0011] When any node waits until it receives a message from the leader node L i When the PRECOMMIT<QC> message is received, the QC is verified. If the verification passes, the local prepareQC is set to QC; if the node stores slices belonging to the current consensus round that reach the second number threshold, it sends a message to the leader node L i Send vote precVote;

[0012] (3) Commit phase: When the leader node L i When the first threshold number of votes precVote is received, L i Package precVote to form certificate QC, and broadcast COMMIT <QC>;

[0013] When any node waits until it receives a message from the leader node L i When receiving the COMMIT<QC> message, verify QC. If the verification passes, take out slices of the second threshold from the locally stored slices to form a slice set S′; use the decoding function of the slicing method to decode S′ and restore the transaction block B′i; for B′ i Calculate hash BHash′ i , if BHash′ i =BHash i , then set the local lockQC to QC and send it to the leader node L i Send vote commitVote;

[0014] (4) Decision stage: When the leader node L i When the first threshold number of votes commitVote is received, L i Package commitVote into certificate QC and broadcast DECIDE<QC>;

[0015] When any node waits until it receives a message from the leader node L i When the DECIDE<QC> message is received, QC is verified. If the verification passes, block B′ is executed i , and send the i+1 round leader node L i+1 Send NEWVIEW message;

[0016] If any of the "wait until" times out in the above (1) to (4) processes, the node will send the i+1 round leader node L i+1 Send a NEWVIEW message.

[0017] On the other hand, a slicing-based pipeline consensus method is provided, which is implemented based on the slicing-based consensus method;

[0018] Each round of pipeline consensus is abstracted into two stages: leader node broadcast and slave node voting to leader node; i After completing the proposal broadcast, L i Immediately delegate the execution rights of the remaining steps in round i to the leader node L of the next round i+1 i+1 After receiving the proposal of round i, the node will send the vote to the leader node L of the next round i+1 i+1 ; When the leader node L i+1 When the first threshold of votes is collected, the right activation can be confirmed, the proposal of round i+1 is broadcast, and the content of the pre-submission phase of round i is executed; when the leader node L i+2 When Nf votes are collected, the rights activation can be confirmed, the proposal of round i+2 is broadcast, and the content of the pre-submission phase of round i+1 and the content of the submission phase of round i are executed; and so on. After receiving the proposal, each slave node will send the vote to the next leader node to complete the transfer of proposal rights and form a consensus in the pipeline.

[0019] The beneficial effects of the present invention are as follows:

[0020] The present invention uses a slicing-based consensus method to slice transaction blocks, which reduces the communication load of the leader node broadcasting proposals, balances the bandwidth consumption of the entire network, and improves the performance and scalability of the blockchain system under low-bandwidth conditions. In the present invention, nodes transmit messages with a communication complexity of O(1), eliminating the bottleneck problem of the leader node without adding additional consensus rounds.

[0021] On this basis, the slice-based pipeline consensus method of the present invention further improves the consensus efficiency through pipeline design. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a flowchart of a slice-based consensus method according to an embodiment of the present invention.

[0023] Figure 2 This is a flowchart of a slice-based pipeline consensus method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The present invention will be described in detail below based on the accompanying drawings and preferred embodiments. The purpose and effects of the present invention will become more apparent. The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0025] like Figure 1 As shown in the figure, a consensus method based on slicing is proposed. In this method, the transaction blocks in each round of consensus proposal are sliced, and proposals containing different slices are sent to each node in the blockchain system. After receiving the slices, each node recovers the information of the original transaction block through communication and collaboration. The message of the recovery process is piggybacked by the consensus message, and the recovery process occurs naturally in the consensus process without generating additional communication rounds. This method relies on a semi-synchronous network model to ensure activity. In a blockchain system with a total number of nodes N, it can tolerate the number of Byzantine nodes. The consensus rounds of this method are marked by a monotonically increasing i. Each consensus round includes the following steps:

[0026] (1) Preparation phase: When the leader node L in round i i When waiting to collect the first threshold number of NEWVIEW messages of round i-1, L i Package NEWVIEW into certificate QC, and take out batchsize of transactions from the local transaction pool and package them into block B of the current round. i , and calculate the block's hash BHash i ; Leader node L i The encoding function of block B is used in the slicing method i Encode and obtain a slice set S containing N slices. Leader node L i Generate a proof for each slice in the slice set S to form a proof set P; the leader node L u Generate proposal collection Leader node L i Send a proposal PROPOSAL to node k k ∈Proposals;

[0027] Any node k waits until it receives PROPOSAL k When verifying p k And QC, if the verification is passed, store <r,s k >, broadcast the received slice and its proof echo<r,s k ,p k > and send it to the leader node L i Send prepareVote; when other nodes receive the slice echo<r,s from node k k ,p k >, verify p k If the verification is successful, store s k ;;

[0028] In this embodiment, the first threshold is Nf. Because Byzantine nodes exist in the system, they can maliciously send false voting messages or cause the messages received by nodes to differ. Therefore, when a node receives Nf votes, at least N-2f of them are from correct nodes, ensuring consistency.

[0029] The leader node in each round is determined by a deterministic algorithm. That is, each node runs the same leader election algorithm, inputting round number i into the algorithm, and is guaranteed to obtain the same result. Slicing-based consensus methods are inherently insensitive to the leader election method, and a variety of algorithms are available, such as fixed leader nodes, round-robin leader election, and network-aware weighted leader election.

[0030] Use the slicing method to slice the blocks in the proposal. The slicing method used provides encoding and decoding functions; the encoding function can convert the input block B i Form N slices of the same size; the decoding function can use the second threshold number of slices in the N slices to decode the original block B i ; wherein the second threshold number is less than or equal to the first threshold number. In this embodiment, the encoding function of the slicing method uses an erasure code of {N, Nf} for slicing, where N indicates the number of equal parts that the erasure code can encode the block into, where f parts are redundant, that is, a set S consisting of any Nf slices is used. i ′ The original block B can be decoded i This parameter is sufficient for slicing-based consensus methods because, under the semi-synchronous assumption, nodes will receive at least Nf slices after global stability; otherwise, a timeout is triggered to ensure consensus liveness. Slicing-based consensus methods are insensitive to the specific erasure code algorithm, and a variety of algorithms are available, such as Reed Solomon erasure codes.

[0031] Leader node L i Generate a proof for each slice in the slice set S, specifically the leader node L i Build a Merkle tree for the slice set S, generate a Merkle path proof containing each Merkle leaf node and the root hash r of the Merkle tree.

[0032] (2) Pre-commit phase: When the leader node L i When the first threshold number of prepareVote votes is received, L i Package prepareVote into certificate QC and broadcast PRECOMMIL <QC>;

[0033] When any node waits until it receives a message from the leader node L iWhen the PRECOMMIT<QC> message is received, the QC is verified. If the verification passes, the local prepareQC is set to QC; if the node stores slices belonging to the current consensus round that reach the second number threshold, it sends a message to the leader node L i Send vote precVote;

[0034] (3) Commit phase: When the leader node L i When the first threshold number of votes precVote is received, L i Package precVote to form certificate QC and broadcast COMMIT <QC>;

[0035] When any node waits until it receives a message from the leader node L i When receiving the COMMIT<QC> message, verify QC. If the verification passes, take out any slices of the second threshold from the locally stored slices to form a slice set S′; then use an erasure code with parameters {N, Nf} to decode S′ and restore the transaction block B′ i ; for B′ i Calculate hash BHash′ i , if BHash′ i =BHash i , then set the local lockQC to QC and send it to the leader node L i Send a vote commitVote.

[0036] In this embodiment, the second quality threshold is also Nf. The second quality threshold should be less than or equal to the first quality threshold.

[0037] (4) Decision stage: When the leader node L i When the first threshold number of votes commitVote is received, L i Package commitVote into certificate QC and broadcast DECIDE<QC>;

[0038] When any node waits until it receives a message from the leader node L i When the DECIDE<QC> message is received, QC is verified. If the verification passes, block B′ is executed i , and send the i+1 round leader node L i+1 Send NEWVIEW message;

[0039] If any of the "wait until" times out in the above (1) to (4) processes, the node will send the i+1 round leader node L i+1 Send a NEWVIEW message.

[0040] Furthermore, each slice requires an identifier that verifies that the slice belongs to the same block, as well as a proof that the slice's correctness can be verified by any node. Slice-based consensus methods are insensitive to the specific slice proof method used. Slice proofs can be constructed using a Merkle tree. A Merkle tree is constructed using slices from the slice set S as Merkle tree nodes, with the Merkle tree root as the unique identifier and the Merkle path of each Merkle branch as the slice proof.

[0041] Furthermore, this method uses signatures to verify and identify node identities; node signatures cannot be forged, and nodes hold the public keys of others to verify signatures from other nodes. The slicing-based consensus method is insensitive to the specific signature algorithm used, and a variety of algorithms are available, such as Rabin signatures, DSS signatures, and RSA signatures.

[0042] Furthermore, this method uses a certificate (QC) as a credential for round advancement. Upon receiving the certificate, a node can confirm that at least a first threshold number of nodes agree to the round's advancement. The slicing-based consensus method is insensitive to the algorithm used to generate the certificate, and a variety of algorithms are available. For example, the size of a certificate generated using a signature list tends to grow in O(N) size as the number of nodes in the system increases. Using aggregate signatures (BLS), a certificate of size O(1) can be generated.

[0043] Furthermore, all nodes communicate with an O(1) overhead, balancing bandwidth consumption across the entire network. The leader node's broadcast includes the broadcast of blocks and the broadcast of certificates (QCs). Using aggregate signatures, the pipeline consensus method reduces the leader node's broadcast overhead to O(1). The remaining nodes' communication consists of one round of slice broadcasts and one vote, so the communication overhead for all nodes in the pipeline consensus method is O(1).

[0044] like Figure 2 As shown, a slicing-based pipeline consensus method is implemented based on the slicing-based consensus method;

[0045] Each round of pipeline consensus is abstracted into two stages: leader node broadcast and slave node voting to leader node; i After completing the proposal broadcast, L i Immediately delegate the execution rights of the remaining steps in round i to the leader node L of the next round i+1 i+1 After receiving the proposal of round i, the node will send the vote to the leader node L of the next round i+1 i+1 ; When the leader node L i+1 When the first threshold of votes is collected, the right activation can be confirmed, the proposal of round i+1 is broadcast, and the content of the pre-submission phase of round i is executed; when the leader node Li+2 When Nf votes are collected, the rights activation can be confirmed, the proposal of round i+2 is broadcast, and the content of the pre-submission phase of round i+1 and the content of the submission phase of round i are executed; and so on. After receiving the proposal, each slave node sends the vote to the next leader node to complete the transfer of proposal rights and form a consensus in the pipeline.

[0046] The method comprises the following steps:

[0047] (1) Proposal: When the leader node L in round i i When waiting to collect at least the first threshold number of i-1 rounds of VOTE messages, L i Package the VOTE into a certificate QC, and take out batchsize of transactions from the local transaction pool and package them into the current round of block B. i , and calculate the block's hash BHash i ; Leader node L i The encoding function of block B is used in the slicing method i Encode and obtain a slice set S containing N slices; the leader node L i Build a Merkle tree for the slice set S, generate a set P containing the Merkle path proof of each Merkle leaf node and the root hash r of the Merkle tree i . Leader node L i Generate proposal collection r i ,s k , p k ,QC>,s k ∈S,p k ∈P}; leader node L i Send one of the proposals GENECIRC to node k k ∈Generics;

[0048] (2) Voting: When node k waits until it receives a message from the leader node L i GENERIC k When verifying p k And QC, if the verification passes, the slice s is stored k , broadcasts the slice and proof echo of the leader node it received <r,s k ,p k > and send the i+1 round leader node L i+1 Send a vote VOTE;

[0049] If a heavy chain is formed and at least a second threshold number of i-1 rounds of slices are stored locally, the node sets the local genericQC to QC; if a double chain is formed, any second threshold number of i-2 rounds of slices are taken from the locally stored slices to form a slice set S′ i-2 ; Then use the decoding function of the slicing method to decode S′ i-2 Decode and restore transaction block B′ i-2 ; for B′ i-2 Calculate hash BHash′ i-2 , if BHash′ i-2 =BHash i-2 , then set the local lockQC to QC; if a triple chain is formed, execute B′ i-3 transactions in

[0050] In addition, during the proposal and voting process, when any node receives a slice echo<r,s from another node k k ,p k >, verify p k If the verification passes, store this slice s k .

[0051] In addition, after the leader node collects votes of the first threshold number, it selects the block tree node b′ pointed to by the QC in the highest round of voting, and creates a new child node b from b′ as the position of the transaction block of this round of consensus in the ledger; when the node receives a proposal containing tree node b, if b's father tree node b′ is a tree node in the QC that verifies b, then b forms a heavy chain; if b forms a heavy chain, and b's father tree node b′ forms a heavy chain, then b forms a double chain; if b forms a double chain, and b's father tree node's father tree node b″ forms a heavy chain, then b forms a triple chain.

[0052] Those skilled in the art will understand that the foregoing descriptions are merely preferred embodiments of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art will still be able to modify the technical solutions described in the foregoing examples or substitute equivalents for some of the technical features therein. Any modifications, equivalent substitutions, etc. made within the spirit and principles of the invention shall be included within the scope of protection of the invention.

Claims

1. A consensus method based on slicing, characterized in that: This method slices the transaction blocks in each round of consensus proposals and sends proposals containing different slices to each node in the blockchain system. After receiving the slices, each node collaborates through communication to restore the information of the original transaction block. The recovery process is piggybacked by the consensus message. The recovery process occurs naturally in the consensus process without generating additional communication rounds. This method relies on a semi-synchronous network model to ensure activity. It can tolerate the number of Byzantine nodes in a blockchain system with a total number of nodes N. The consensus rounds of this method are marked by a monotonically increasing i. Each consensus round includes the following steps: (1) Preparation phase: When the leader node L in round i i When the NEWVIEW messages of round i-1 reaching the first threshold are collected, L i Package NEWVIEW into certificate QC, and take out batchsize transactions from the local transaction pool and package them into block B of the current round. i , and calculate the block's hash BHash i ; Leader node L i The encoding function of B using the slicing method i Encode and obtain a slice set S containing N slices; the leader node L i Generate a proof for each slice in the slice set S to form a proof set P; the leader node L i Generate proposal collection Leader node L i Send a proposal PROPOSAL to node k k ∈Proposals; Any node k waits until it receives PROPOSAL k When verifying p k And QC, if the verification passes, the slice s is stored k , broadcasts the received slice and its proof echo k , p k >, and send it to the leader node L i Send a vote prepareVote; when other nodes receive the slice and its proof echo from node k k , p k >, verify p k If the verification is successful, store s k ;​​ (2) Pre-commit phase: When the leader node L i When the first threshold number of prepareVote votes is received, L i Package prepareVote into certificate QC and broadcast PRECOMMIT <qc> ；< / qc> When any node waits until it receives a message from the leader node L i PRECOMMIT <qc>When receiving a message, verify QC. If the verification passes, set the local prepareQC to QC. If the node stores slices belonging to the current consensus round that reach the second number threshold, send a message to the leader node L. i Send vote precVote;< / qc> (3) Commit phase: When the leader node L i When the first threshold number of votes precVote is received, L i Package precVote to form certificate QC and broadcast COMMIT <qc> ；< / qc> When any node waits until it receives a message from the leader node L i COMMIT <qc>When receiving a message, QC is verified. If the verification passes, slices of the second threshold are taken from the locally stored slices to form a slice set S'; the decoding function of the slicing method is used to decode S' and restore the transaction block B' i ; for B′ i Calculate hash BHash′ i , if BHash′ i =BHash i , then set the local lockQC to QC and send it to the leader node L i Send vote commitVote;< / qc> (4) Decision stage: When the leader node L i When the first threshold number of votes commitVote is received, L i Package commitVote into certificate QC and broadcast DECIDE <qc> ；< / qc> When any node waits until it receives a message from the leader node L i DECIDE <qc>When the message is received, QC is verified. If the verification passes, block B' is executed. i , and send the i+1 round leader node L i+1 Send NEWVIEW message;< / qc> If any of the "wait until" times out in the above (1) to (4) processes, the node will send the i+1 round leader node L to the node. i+1 Send a NEWVIEW message.

2. The slice-based consensus method according to claim 1, characterized in that: The leader node of each round is determined by a deterministic algorithm, that is, each node runs the same leader election algorithm, inputs the round i into the algorithm, and is sure to get the same result.

3. The slice-based consensus method according to claim 1, characterized in that: Use the slice method to slice the blocks in the proposal; the slice method used provides encoding and decoding functions; The encoding function can transform the input block B i Form N slices of the same size; The decoding function can decode the original block B using a second threshold number of slices in the N shares. i ; wherein the second threshold quantity is less than or equal to the first threshold quantity.

4. The slice-based consensus method according to claim 1, characterized in that: For each slice, an identifier that can verify that the slice belongs to the same block and a proof that the correctness of the slice can be verified by any node are required. The proof is unforgeable.

5. The slice-based consensus method according to claim 1, characterized in that: This method uses signatures to verify and identify node identities; the node's signature cannot be forged, and the node holds the public key of others to verify signatures from other nodes.

6. The slice-based consensus method according to claim 1, characterized in that: The method uses the certificate QC as a credential for round advancement. The generation of the certificate requires at least a first threshold number of votes, and the certificate is unforgeable.

7. A slicing-based pipeline consensus method, characterized in that: The method is implemented based on the slice-based consensus method described in any one of claims 1 to 6; Each round of pipeline consensus is abstracted into two stages: leader node broadcasting and slave nodes voting to the leader node; On the leader node L i After completing the proposal broadcast, L i Immediately delegate the execution rights of the remaining steps in round i to the leader node L of the next round i+1 i+1 After receiving the proposal of round i, the node will send the vote to the leader node L of the next round i+1 i+1 ; When the leader node L i+1 When the first threshold of votes is collected, the rights are activated, the proposal for round i+1 is broadcast, and the content of the pre-submission phase of round i is executed; When the leader node L i+2 When Nf votes are collected, the rights activation is confirmed, the proposal for round i+2 is broadcast, and the contents of the pre-submission phase of round i+1 and the contents of the submission phase of round i are executed; Similarly, after receiving the proposal, each slave node will send the vote to the next leader node, thereby completing the transfer of proposal rights and forming a consensus in the pipeline.

8. The pipeline consensus method according to claim 7, characterized in that: The method comprises the following steps: (1) Proposal: When the leader node L in round i i When at least the first threshold number of i-1 rounds of VOTE messages are collected, L i Package the VOTE into a certificate QC, and take out batchsize of transactions from the local transaction pool and package them into the current round of block B. i , and calculate the block's hash BHash i ; Leader node L i The encoding function of B using the slicing method i Encode and obtain a slice set S containing N slices; the leader node L i Generate a proof for each slice in the slice set S to form a proof set P; the leader node L i Generate proposal collection Leader node L i Send one of the proposals GENECIRC to node k k ∈Generics; (2) Voting: When node k waits until it receives a message from the leader node L i GENERIC k When verifying p k And QC, if the verification passes, the slice s is stored k , broadcasts the slice and proof echo of the leader node it received k , p k >, and send the i+1 round leader node L i+1 Send a vote VOTE;​ If a heavy chain is formed and at least a second threshold number of i-1 rounds of slices are stored locally, the node sets the local genericQC to QC; if a double chain is formed, any second threshold number of i-2 rounds of slices are taken from the locally stored slices to form a slice set S′ i-2 ; Decoding function using slicing method for S′ i-2 Decode and restore transaction block B′ i-2 ; for B′ i-2 Calculate hash BHash′ i-2 , if BHash′ i-2 =BHash i-2 , then set the local lockQC to QC; if a triple chain is formed, execute B′ i-3 transactions in In addition, during the proposal and voting process, when any node receives a slice and its proof echo from another node k k , p k >, verify p k If the verification passes, store this slice s k .​ 9. The slicing-based pipeline consensus method according to claim 7, characterized in that: After the leader node collects votes of the first threshold number, it selects the block tree node b′ pointed to by qC in the vote with the highest round, and creates a new child node b from b′ as the position of the transaction block of this round of consensus in the ledger; when the node receives a proposal containing tree node b, if b's father tree node b′ is a tree node in qC that verifies b, then b forms a heavy chain; if b forms a heavy chain, and b's father tree node b′ forms a heavy chain, then b forms a double chain; if b forms a double chain, and b's father tree node's father tree node b″ forms a heavy chain, then b forms a triple chain.

Images