Method and system for optimizing consensus mechanism of alliance block chain

Abstract

The invention provides an optimization method and system for an alliance block chain consensus mechanism, and belongs to the technical field of the alliance block chain consensus mechanism, a multi-leader node mode and a multi-chain DAG storage architecture are adopted, under the mode and the architecture, when a certain leader node is delayed or has an error, other normal nodes can still continue proposal and processing, and the optimization efficiency of the alliance block chain consensus mechanism is improved. And a node rotation mode does not need to be entered, so that the problems of system stagnation, high resource consumption, difficulty in view processing and the like during leader rotation are avoided. Parallelization processing of consensus transactions is achieved based on multiple threads, each replica node processes proposal actions and voting actions of the replica node and proposal actions and voting behaviors of other replica nodes at the same time in a multi-thread mode, and high concurrency consensus can be achieved. And meanwhile, decoupling optimization is performed on block consensus, and a consensus mechanism is constructed from two aspects of view consensus and execution consensus by using a threshold signature algorithm, a two-section consensus, a block request mechanism and an expectation set construction model.

Description

Technical Field

[0001] The present invention relates to the technical field of alliance blockchain consensus mechanism, and in particular to an optimization method and system for an alliance blockchain consensus mechanism. Background Art

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

[0003] Therefore, this field urgently needs a technical solution that can improve the consensus efficiency while ensuring the security of the alliance chain consensus.

[0004] The information disclosed in this background technology section is only intended to enhance the understanding of the overall background of the invention and should not be regarded as an acknowledgment or any form of suggestion that the information constitutes the prior art already known to a person skilled in the art. Summary of the invention

[0005] The purpose of this invention is to provide a technical solution that can improve the consensus efficiency while ensuring the security of the alliance chain consensus.

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

[0007] A method for optimizing a consensus mechanism of a consortium blockchain, comprising:

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

[0009] The proposal node makes a proposal;

[0010] Generate proposal blocks and send them to other nodes;

[0011] Other nodes verify the signature of the referenced block;

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

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

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

[0015] Conduct expected set construction model judgment;

[0016] Determine whether it is an expected block;

[0017] If it is an expected block, the block transaction of the expected set is executed and the execution result is returned to the client;

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

[0019] Other nodes validate the proposed block itself;

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

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

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

[0023] An optimization system for a consortium blockchain consensus mechanism, comprising:

[0024] Multi-leader mode and multi-chain DAG structure module, used to realize parallel processing of consensus transactions based on multi-threading;

[0025] The view consensus module is used to make different replica nodes reach a consensus on the block content and its corresponding height on each chain in the storage view;

[0026] The execution consensus module is used to reach consensus on the execution of blocks by different replica nodes.

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

[0028] Node selection mechanism unit and parallelized transaction processing unit.

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

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

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

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

[0033] The optimization system for the alliance blockchain consensus mechanism according to claim 1 is characterized in that the view consensus module includes a two-stage consensus protocol unit and a block request mechanism unit;

[0034] The two-stage consensus protocol unit is used to divide the block status into three consensus states: executable block, confirmed block and highest block. When a proposal block is proposed, the nodes in the system perform a series of verification steps to ensure the legitimacy of the proposal block and the status of the block it references, specifically:

[0035] The node verifies the signature of the previous block referenced by the proposal block, including checking whether the votes on the referenced block between nodes have reached the voting number threshold required by the consensus, verifying the legitimacy of each signature, and ensuring that all signatures are generated by authorized nodes. If all these verifications are passed, it is considered that the block referenced by the proposal block has reached the confirmed state and is marked as a "confirmed block". In this case, if the referenced block has been confirmed, then the upstream block of the referenced block is further judged. It can be considered that the block that proves the legitimacy of the upstream block is recognized and proven to be valid. Therefore, all upstream blocks are considered to be "executable blocks" and can start executing corresponding transaction operations and add them to the executable queue. When processing a new proposal block, the node must check whether the block is on the correct blockchain branch. The height of the new proposal block must be greater than the height of the confirmed block to ensure the continuity and consistency of the blockchain.

[0036] Optionally, the block request mechanism unit is used to maintain the view between the nodes. Figure 1 Consistency, specifically:

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

[0038] Optionally, the consensus execution module includes an expected set construction model unit, which is used to find an expected set defined as "blocks outside the set must be proposed later than blocks in the set", and the specific steps include:

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

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

[0041] Optionally, the expected set model building unit includes an expected block judgment unit, and the expected block judgment unit is used to judge whether the execution block is an expected block, specifically:

[0042] By comparing the timestamp size of the block with the timestamp of the confirmed block of other chains, if the timestamp of the confirmed block of other chains is greater than this block, that is, the blocks proposed earlier than the confirmed block on the chain are already in the view, then there is no problem of missing view. If the timestamp of the confirmed block of a chain is less than this block, the state of the chain is judged. For example, whether the chain has not continued the proposal or has entered a stagnant state. The basis for judging whether the chain has not continued the proposal or entered a stagnant state is that the timestamp of the confirmed block of the determined chain is greater than the number of times the relevant blocks of this block are referenced SID>(number of copies-(2*f+1)), because in a distributed system, f represents the maximum number of possible faulty nodes. When the timestamp of the relevant blocks with a timestamp greater than this block exceeds this threshold, it means that the number of nodes in the system that exceed the fault tolerance capacity fails to effectively respond or advance the progress, resulting in insufficient nodes on the chain to participate in block proposals or reach consensus, thus entering a stagnant state.

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

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

[0045] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0046] Figure 1 A block consensus flow diagram is provided for an embodiment of the present invention.

[0047] Figure 2 Schematic diagram of the multi-chain DAG structure and multi-leader mode provided for an embodiment of the present invention.

[0048] Figure 3 A schematic diagram of a two-stage consensus provided by an embodiment of the present invention.

[0049] Figure 4 A model is constructed for the desired set provided by the embodiment of the present invention. DETAILED DESCRIPTION

[0050] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] The purpose of this invention is to provide a technical solution that can improve the consensus efficiency while ensuring the security of the alliance chain consensus.

[0052] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0053] Embodiment 1:

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

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

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

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

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

[0059] Node selection mechanism:

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

[0061] Parallelized transaction processing:

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

[0063] View consensus consistency:

[0064] This consensus system is to ensure Figure 1 In order to ensure consistency, the two-stage consensus mechanism is adopted, combined with the threshold signature algorithm, which further improves the efficiency and security of the consensus. Threshold signature distributes the signature rights to multiple nodes. Only when enough nodes agree, the signature will take effect, avoiding single point failure. In addition, this consensus system also introduces a block request mechanism, which allows nodes to request block data from other nodes when there is a view loss. This mechanism helps nodes obtain the latest block information in a timely manner, thereby assisting each node to maintain the view. Figure 1 Consistency.

[0065] Two-phase consensus protocol:

[0066] Two-stage consensus Figure 3 As shown in the figure, the block status can be divided into three consensus states: executable block, confirmed block and highest block. When a proposal block is proposed, the nodes in the system need to perform a series of verification steps to ensure the legitimacy of the proposal block and the status of the block it references.

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

[0068] Algorithm 1: Block consensus state update algorithm

[0069] Input block

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

[0071] (2) if parent block->SIGN is legal then

[0072] (3) Parent block -> Mark as confirmed block

[0073] (4) for blk of upstream block do

[0074] (5)blk->Mark as executable block

[0075] (6)blk->Add to executable queue

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

[0077] Block request mechanism:

[0078] In this consensus system, in order to maintain the visibility between nodes Figure 1 In order to ensure consistency, a block request mechanism is introduced. When a node processes a proposal block, it may encounter a situation where the block referenced by the proposal block is missing in its own local copy storage but has collected enough signatures. This is usually due to network latency, synchronization issues, or a possible loss of view caused by a network attack. Although the block reference is missing, the referenced block itself has passed the signature verification, indicating that the block is legitimate. In order to compensate for this view loss, this consensus system introduces a block request mechanism to request the missing block from the proposer to help the node obtain the missing block data, thereby maintaining the view in the network. Figure 1 Consistency.

[0079] Execution consensus:

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

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

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

[0083] Note: This consensus system adds blocks to the executable queue by simply mapping the hash value corresponding to the block to the queue through the timestamp. During execution, the corresponding block is found from the storage according to the hash value and the corresponding transaction is executed.

[0084] This consensus system compares the timestamp size of the block with that of other chains. If the timestamp of the confirmed block of other chains is greater than that of this block, that is, the blocks proposed earlier than the confirmed block on the chain are already in the view, then there is no problem of missing view. If the timestamp of the confirmed block of a chain is less than that of this block, the state of the chain is judged. For example, whether the chain has not continued the proposal or has entered a stagnant state. The basis for judging whether the chain has not continued the proposal or entered a stagnant state is that the timestamp of the confirmed block of the determined chain is greater than the number of times the relevant blocks of this block are referenced SID>(number of copies-(2*f+1)), because in a distributed system, f represents the maximum number of possible faulty nodes. When the timestamp of the relevant blocks with a timestamp greater than that of this block exceeds this threshold, it means that the number of nodes in the system that exceed the fault tolerance capacity fails to effectively respond or advance the progress, resulting in insufficient nodes on the chain to participate in block proposals or reach consensus, and thus enters a stagnant state. As shown in Algorithm 2:

[0085] Algorithm 2 Expected block judgment algorithm

[0086] Input the block to be judged

[0087] Output TRUE / FALSE

[0088] (1) for all chains do

[0089] (2) Identify block = getIdentifyBlock(chain)

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

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

[0092] (5) if the timestamp of the determined block is less than the timestamp of the determined block then

[0093] (6) if the determined block->getSID(timestamp of the determined block)<(number of copies-(2*f+1))then

[0094] (6) return FALSE

[0095] (7)return TRUE

[0096] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0097] The principles and implementation methods of the present invention are described in this article using specific examples. The description of the above embodiments is only used to help understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A method for optimizing the consensus mechanism of a consortium blockchain, characterized in that: include: The client sends a request to the proposal node The proposal node makes a proposal; Generate proposal blocks and send them to other nodes; Other nodes verify the signature of the referenced block; Other nodes update the consensus status of the upstream blocks on the corresponding chain; Determine whether the upstream block is an executable block; If it is an executable block, add it to the executable queue; Conduct expected set construction model judgment; Determine whether it is an expected block; If it is an expected block, the block transaction of the expected set is executed and the execution result is returned to the client; If it is not the expected block, wait for the subsequent block judgment; Other nodes validate the proposed block itself; Other nodes sign and send the signature to the proposal node; The proposal node receives the signature and synthesizes the final signature; The proposal block is added to storage and waits for the next consensus status update.

2. An optimization system for the consensus mechanism of a consortium blockchain, characterized in that: include: Multi-leader mode and multi-chain DAG structure module, used to realize parallel processing of consensus transactions based on multi-threading; The view consensus module is used to make different replica nodes reach a consensus on the block content and its corresponding height on each chain in the storage view; The execution consensus module is used to reach consensus on the execution of blocks by different replica nodes.

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

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

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

6. The optimization system of the alliance blockchain consensus mechanism according to claim 5 is characterized in that: The tasks include: processing its own block proposals, verifying and signing other node proposals, and receiving and processing proposals and signature information from other replica nodes, specifically: When a node initiates a proposal, it can split and process different tasks in parallel. Independent threads are responsible for block proposal generation, signature verification, and signature collection. The node can also continue to receive proposals from other nodes in another thread and perform signature processing according to the threshold signature algorithm. When some threads are affected by network delays or node failures, other threads can continue to process proposals and voting requests.

7. The optimization system of the alliance blockchain consensus mechanism according to claim 2, characterized in that: The view consensus module includes a two-stage consensus protocol unit and a block request mechanism unit; The two-stage consensus protocol unit is used to divide the block status into three consensus states: executable block, confirmed block and highest block. When a proposal block is proposed, the nodes in the system perform a series of verification steps to ensure the legitimacy of the proposal block and the status of the block it references, specifically: The node verifies the signature of the previous block referenced by the proposal block, including checking whether the votes on the referenced block between nodes have reached the voting number threshold required by the consensus, verifying the legitimacy of each signature, and ensuring that all signatures are generated by authorized nodes. If all these verifications are passed, it is considered that the block referenced by the proposal block has reached the confirmed state and is marked as a confirmed block. In this case, if the referenced block has been confirmed, then the upstream block of the referenced block is further judged. It can be considered that the block that proves the legitimacy of the upstream block is recognized and proven to be valid. Therefore, all upstream blocks are considered to be executable blocks, and the corresponding transaction operations can be started and added to the executable queue. When processing a new proposal block, the node must check whether the block is on the correct blockchain branch. The height of the new proposal block must be greater than the height of the confirmed block to ensure the continuity and consistency of the blockchain.

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

9. The optimization system of the alliance blockchain consensus mechanism according to claim 2, characterized in that: The execution consensus module includes an expected set construction model unit, which is used to find an expected set defined as a block outside the set that must be proposed later than the block inside the set. The specific steps include: Step 1: Sort the executable blocks according to timestamps and add them to the executable queue; Step 2: Determine whether the newly added block is the expected block defined as the last proposed block in the expected set. If so, execute the block and the unexecuted blocks in the expected set it constitutes; if not, wait for the judgment of subsequent blocks.

10. The optimization system of the alliance blockchain consensus mechanism according to claim 10, characterized in that: The expected set model building unit includes an expected block judgment unit, which is used to judge whether the execution block is an expected block, specifically: By comparing the timestamp size of the block with the timestamp of the confirmed block of other chains, if the timestamp of the confirmed block of other chains is greater than this block, that is, the blocks proposed earlier than the confirmed block on the chain are already in the view, then there is no problem of missing view. If the timestamp of the confirmed block of a chain is less than this block, the status of the chain is judged, such as whether the chain has not continued to propose or has entered a stagnant state. The basis for judging whether the chain has not continued to propose or has entered a stagnant state is that the timestamp of the confirmed block of the judged chain is greater than the number of times the relevant blocks of this block are referenced SID>(number of copies-(2*f+1)). This is because in a distributed system, f represents the maximum number of possible faulty nodes. When the timestamp of the relevant blocks with a timestamp greater than this block exceeds this threshold, it means that the number of nodes in the system that exceed the fault tolerance capacity fails to effectively respond or advance the progress, resulting in insufficient nodes on the chain to participate in block proposals or reach consensus, and thus enters a stagnant state.

Images