Asynchronous consensus method and system based on reputation scoring and dual-path switching
By selecting a leader node in a DAG-type consensus protocol through a reputation scoring mechanism and switching to a pessimistic path when the timeout fails, the problem of balancing low latency and system activity in an asynchronous network environment for DAG-type consensus protocols is solved, achieving low latency, high throughput, and high reliability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HAINAN UNIV
- Filing Date
- 2026-01-30
- Publication Date
- 2026-05-01
AI Technical Summary
Existing DAG-based Byzantine fault-tolerant consensus protocols struggle to simultaneously achieve low-latency block submissions and reliable system activity in a fully asynchronous network environment, and cannot balance low latency and system activity in complex adversarial environments.
An asynchronous consensus method based on reputation scoring and dual-path switching is adopted. A leader node is pre-selected in the optimistic execution path and anchor blocks are pre-submitted within the timeout period. If the timeout is unsuccessful, the path is switched to the pessimistic execution path. A global random coin mechanism is used to elect a temporary leader node to advance the consensus, and the decision is made based on the causal reference relationship of the anchor blocks.
It achieves low-latency block submission and high throughput in an asynchronous network environment, and maintains system activity when network conditions deteriorate. It selects nodes with fast response speed through a reputation scoring mechanism, reduces the probability of slow or abnormal nodes being elected as leader nodes, and improves consensus efficiency and system robustness.
Smart Images

Figure CN121967429A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of distributed computing, and more specifically, relates to an asynchronous consensus method and system based on reputation scoring and dual-path switching. Background Technology
[0002] With the increasing demand for high-throughput and low-latency consensus in blockchain and distributed systems, Byzantine fault-tolerant consensus protocols based on Directed Acyclic Graphs (DAGs) have gradually become a research hotspot. Compared to traditional chain-based consensus structures, DAG-based consensus protocols can effectively improve the parallelism and overall throughput performance of the system through parallel propagation and sorting of blocks. However, existing DAG-based consensus protocols still have certain shortcomings in terms of leader selection efficiency, system liveness assurance, and resistance to malicious attacks. DAG-Rider is one of the earlier proposed asynchronous DAG consensus protocols. It divides the consensus process into multiple waves consisting of several rounds, and elects a leader node in the first round of each wave. Although this protocol can guarantee system security and liveness in a completely asynchronous network environment, its block submission latency is relatively high, with an expected block submission latency of approximately 12 communication steps, which is difficult to meet the needs of low-latency application scenarios. Based on this, the Bullshark protocol introduces partial synchronization assumptions and optimizes the DAG-Rider submission process, which can reduce the leader block submission latency to 6 communication steps under ideal network conditions. To further reduce consensus latency, protocols such as Shoal introduce a reputation-based leader pre-election mechanism, thereby reducing the probability of slow or abnormal nodes being elected as leaders. However, both Bullshark and Shoal are only applicable to partially synchronous network environments. In asynchronous network conditions or when subjected to denial-of-service attacks targeting the leader node, the system loses its activity. In summary, existing DAG-based consensus protocols either have high commit latency in asynchronous environments or rely on partially synchronous assumptions, making it difficult to simultaneously achieve low latency and system activity in complex adversarial environments.
[0003] Therefore, how to address the shortcomings of existing DAG-type Byzantine fault-tolerant consensus protocols in a completely asynchronous network environment, which make it difficult to simultaneously achieve low-latency block submission and reliable system activity, and thus achieve low latency, high throughput, and improved reliability, is a technical problem that urgently needs to be solved. Summary of the Invention
[0004] In view of the shortcomings of the prior art, the purpose of this application is to address the difficulty in achieving both low-latency block submission and reliable system activity in the prior art, thereby achieving low latency, high throughput and improved reliability.
[0005] To achieve the above objectives, in a first aspect, this application provides an asynchronous consensus method based on reputation scoring and dual-path switching, running on an asynchronous Byzantine fault-tolerant distributed system, wherein the distributed system includes at least 3f+1 nodes, where f is the upper limit of the number of fault-tolerant nodes, and the method includes: A reputation score is calculated based on the behavior of each node in the current consensus epoch, and the set of leader nodes for the next consensus epoch is determined based on the reputation score to enter the optimistic execution path. In the optimistic execution path, the consensus process is led by the nodes in the leader node set, and the anchor block of the current consensus cycle is pre-submitted within a preset timeout period in order to enter the optimistic execution path of the next consensus cycle. If the anchor block is not successfully submitted within the timeout period, the pessimistic execution path is switched to, and a temporary leader node is elected through the Global Perfect Coin (GPC) mechanism to advance consensus and generate a new candidate block. Determine whether the new candidate block can indirectly reference the anchor block: if yes, submit the anchor block to roll back to the optimistic execution path; if no, promote the new candidate block to the updated anchor block, recalculate the reputation score based on the updated anchor block, and determine a new set of leader nodes to start a new optimistic execution path.
[0006] Optionally, the execution process of the optimistic execution path includes: In the optimistic execution path, the consensus process is advanced in rounds, and each node propagates blocks based on a directed acyclic graph structure; The nodes in the set of leader nodes are arranged in a predetermined order and serve as leader nodes in their respective designated rounds. The blocks generated by the leader nodes constitute the leader blocks for each round. When the preset direct commit conditions are met, the corresponding leader block and all historical leader blocks and their corresponding ancestor blocks that have a path relationship but have not yet been committed are committed. Set a timeout timer. If the anchor block for the current consensus period is successfully submitted before the timeout, the reputation score and leader node pre-selection are performed based on the anchor block.
[0007] Optionally, the process of obtaining the reputation score and the set of leader nodes includes: Once the anchor block of the current consensus period is submitted, the leader nodes with the determined order within the current consensus period are traversed. For each leader node traversed, if the generated block references a block from the previous round, a positive score is added to the reputation score of the node corresponding to the leader node, so as to accumulate the final reputation score of each node. Based on the final reputation scores of all nodes in this cycle, a predetermined number of nodes with the highest rankings are selected to form the leader node set for the next consensus cycle.
[0008] Optionally, the submission process for the anchor block includes: For the leader block generated in round r, when a node receives the first message of at least 2f+1 blocks in round r+1, and the blocks corresponding to the 2f+1 first messages all reference the leader block of round r, the node directly submits the leader block of round r; where r is the round number. Alternatively, if a node delivers at least f+1 blocks in round r+1 that all reference the leader block of round r, then the node directly submits the leader block of round r. After directly committing a leader block, the node backtracks along the local directed acyclic graph, in turn indirectly committing all uncommitted historical leader blocks reachable by reference paths, until it encounters a committed leader block.
[0009] Optionally, the pessimistic execution path steps specifically include: Advancement is based on waves, with each wave consisting of a hierarchical reliable broadcast round and a consistent broadcast round; Once a node has delivered at least nf blocks of level 2, it broadcasts the new blocks via the consensus broadcast protocol to advance to the next round; where n is the total number of nodes. In the consensus broadcast round, each node generates and broadcasts a block that includes the parameters for invoking the global random coin. At the end of the wave, each node, based on the output of the global random coin, jointly elects a temporary leader node, and the block generated by the temporary leader node in the corresponding round is used as the new candidate block.
[0010] Optionally, a synchronization constraint mechanism is also included before the optimistic execution path enters the next consensus cycle; The synchronization constraint mechanism specifically includes: When a node submits the anchor block for the current consensus period before the timeout, it broadcasts a submission message. A node broadcasts the commit message after receiving at least f+1 identical commit messages for the same anchor block; Once a node has collected at least 2f+1 identical commit messages, it aggregates the commit messages into a commit certificate and broadcasts it. Once a node obtains the submission certificate, it enters the optimistic execution path of the next consensus cycle and broadcasts a new block. If the submission certificate is not obtained before the timeout timer expires, a forced switch to the pessimistic execution path will be initiated.
[0011] Optionally, determining whether the new candidate block can indirectly reference the anchor block includes: Determine whether the temporary leader node can indirectly reference the anchor block in the optimistic execution path of the current consensus cycle through a directed path; if it exists, it is determined that it can be indirectly referenced; if it does not exist, it is determined that it cannot be indirectly referenced.
[0012] Optionally, under the optimistic execution path, the leader node propagates its blocks using the Reliable Broadcast (RBC) protocol in its round; the non-leader node propagates its blocks using the Consistent Broadcast (CBC) protocol in its round.
[0013] Secondly, this application provides an asynchronous consensus system based on reputation scoring and dual-path switching, comprising: The reputation scoring module is used to calculate the reputation score based on the behavior of each node in the current consensus cycle, and to determine the set of leader nodes for the next consensus cycle based on the reputation score, so as to enter the optimistic execution path. The optimistic path module is used to lead the consensus process through the nodes in the leader node set in the optimistic execution path, and to pre-submit the anchor block of the current consensus cycle within a preset timeout period in order to enter the optimistic execution path of the next consensus cycle. The pessimistic path module is used to switch to the pessimistic execution path if the anchor block is not successfully submitted within the timeout period, and to promote consensus by electing a temporary leader node through a global random coin mechanism to generate a new candidate block. The judgment module is used to determine whether the new candidate block can indirectly reference the anchor block: if yes, the anchor block is submitted to roll back to the optimistic execution path; if no, the new candidate block is promoted to the updated anchor block, the reputation score is recalculated based on the updated anchor block, and a new set of leader nodes is determined to start a new optimistic execution path.
[0014] Thirdly, this application provides an electronic device, comprising: at least one memory for storing a program; and at least one processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to execute the method described in the first aspect or any possible implementation thereof.
[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to perform the method described in the first aspect or any possible implementation thereof.
[0016] Fifthly, this application provides a computer program product that, when run on a processor, causes the processor to perform the method described in the first aspect or any possible implementation thereof.
[0017] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.
[0018] Overall, the technical solutions conceived in this application have the following beneficial effects compared with the prior art: (1) This application constructs an optimistic execution path by pre-selecting leader nodes based on a reputation scoring mechanism, enabling low-latency direct block submission and high-throughput parallel processing under normal network conditions. By using a pre-set timeout mechanism and a pessimistic execution path driven by a global random coin, the dual-path mechanism can fully leverage the low-latency advantage brought by the reputation mechanism when network conditions are good, and promptly back off when network conditions deteriorate or the fast path is blocked, avoiding protocol stagnation, thereby balancing consensus efficiency and system robustness, and improving the system's adaptability in complex network environments; the scheme of this application combines the high performance of the optimistic path with the system activity of the pessimistic path, achieving a unity of performance and activity in asynchronous environments.
[0019] (2) This application continuously scores nodes and pre-selects the leader nodes for subsequent consensus stages, so that nodes with fast response speed and high participation rate take the lead role, thereby reducing the probability of slow or abnormal nodes being selected as leader nodes, reducing consensus waiting time, shortening block submission path, improving block submission efficiency, and effectively reducing the overall consensus delay of the system when network conditions are good.
[0020] (3) The consensus mechanism of this application is executed along the fast path when the network conditions are good, and low-latency block submission is achieved through pre-selection of leader nodes; when the anchor block in the fast path cannot meet the submission conditions within a preset time, it automatically switches to the pessimistic path and continues to advance the consensus through randomized leader node election, so as to ensure the system activity under asynchronous or bad network conditions and avoid consensus stagnation due to the failure of fixed leader nodes or attacks.
[0021] (4) In the pessimistic path, this application randomly elects a temporary leader node and determines whether to retain or skip the original anchor block based on the causal reference relationship between the temporary leader node and the previous fast path anchor block. When the temporary leader node cannot indirectly reference the original anchor block, it is promoted to the new anchor block. When the temporary leader node can indirectly reference the original anchor block, it rolls back to the optimistic path. This mechanism prevents different nodes from generating inconsistent consensus results under different execution paths, ensuring that the system can still maintain security and activity even in the event of inconsistent node states or denial-of-service attacks. Attached Figure Description
[0022] Figure 1 This is a flowchart illustrating the asynchronous consensus method based on reputation scoring and dual-path switching provided in an embodiment of this application. Figure 2 This is a schematic diagram of the optimistic execution path in an embodiment of this application; Figure 3 This is a schematic diagram of the pessimistic execution path in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the relationship between throughput and end-to-end latency for different protocols in the case where the embodiment of this application consists of 10 nodes and there are no Byzantine nodes. Figure 5 This is a schematic diagram illustrating the relationship between throughput and end-to-end latency for different protocols in the case where the embodiment of this application consists of 16 nodes and there are no Byzantine nodes. Figure 6 This is a schematic diagram illustrating the relationship between throughput and end-to-end latency for different protocols in the case of a system consisting of 10 nodes and 3 Byzantine nodes in this embodiment of the application. Figure 7 This is a schematic diagram illustrating the relationship between throughput and end-to-end latency for different protocols in an embodiment of this application consisting of 16 nodes and 5 Byzantine nodes. Figure 8 This is a schematic diagram of the structure of the asynchronous consensus method device based on reputation scoring and dual-path switching provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0024] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.
[0025] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.
[0026] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0027] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.
[0028] The embodiments of this application are described below with reference to the accompanying drawings.
[0029] Reference Figure 1 This application provides an asynchronous consensus method based on reputation scoring and dual-path switching, running on an asynchronous Byzantine fault-tolerant distributed system. The distributed system includes at least 3f+1 nodes, where f is the upper limit of the number of fault-tolerant nodes. The method includes: S101. Calculate the reputation score based on the behavior of each node in the current consensus cycle, and determine the set of leader nodes for the next consensus cycle based on the reputation score, so as to enter the optimistic execution path of the next consensus cycle; S102. In the optimistic execution path, the consensus process is led by the nodes in the leader node set, and the anchor block of the current consensus cycle is pre-submitted within a preset timeout period to enter the optimistic execution path of the next consensus cycle. S103. If the anchor block is not successfully submitted within the timeout period, switch to the pessimistic execution path, elect a temporary leader node through a global random coin mechanism to advance consensus, and generate a new candidate block; S104. Determine whether the new candidate block can indirectly reference the anchor block: if yes, submit the anchor block to roll back to the optimistic execution path; if no, promote the new candidate block to the updated anchor block, recalculate the reputation score based on the updated anchor block and determine the leader node set for the next consensus cycle to start a new optimistic execution path.
[0030] Specifically, this application aims to simultaneously achieve low-latency block submission and high-reliability system liveness in a fully asynchronous network environment. The method operates in a Byzantine fault-tolerant distributed system consisting of at least 3f+1 nodes, where f represents the maximum number of faulty nodes the system can tolerate.
[0031] It should be further noted that an adaptive attacker may exist in the system, capable of controlling up to f nodes and causing them to behave arbitrarily, thus acting as a Byzantine node, while the remaining nodes are considered non-faulty nodes. The attacker's computational capabilities are limited to ensure the security of the cryptographic primitives used in this application.
[0032] Specifically, the public key infrastructure, threshold signature mechanism, and digital signature mechanism relied upon in this application are all considered secure under the stated attack model, thus ensuring that signatures cannot be forged, messages cannot be tampered with undetected, and there are no feasible hash collision attacks. During consensus execution, this application introduces a Global Perfect Random Coin (GPC) mechanism to provide necessary randomness. This random coin mechanism uses a threshold trigger condition of f+1, and when at least f+1 nodes participate in the call, it can generate consistent and unpredictable random results. The system network model assumes a completely asynchronous environment, meaning that message transmission delay has no upper bound; attackers can arbitrarily delay message delivery, but must ensure that any message sent by a non-faulty node can eventually be received by other non-faulty nodes. Any two nodes in the system are connected via a reliable point-to-point communication link. During communication, the receiving node authenticates the message sender's identity using cryptographic means to ensure the authenticity and integrity of the message source.
[0033] Firstly, through S101, at the beginning of each consensus cycle, the reputation score of each node is dynamically calculated based on its historical behavior in the previous cycle. Specifically, the reputation score is obtained by quantifying and accumulating key behaviors of a node in the consensus process, such as whether it generates and correctly references previous blocks when acting as a leader node. Based on this score, all nodes are ranked, and a few high-reputation nodes with the highest rankings are selected to form the leader node set for the next consensus cycle. This ensures that the consensus process is more likely to be dominated by high-quality nodes with fast network response and stable behavior. It should be noted that each consensus cycle in this application ends with the submission of the anchor block.
[0034] Secondly, in S102, the system enters an optimistic execution path dominated by the set of leader nodes. Under this path, consensus progresses in rounds, with all nodes propagating blocks in parallel based on a directed acyclic graph structure. Pre-selected leader nodes perform their duties in designated rounds according to a predetermined order, and the blocks they generate are identified as leader blocks. Each node sets a preset timeout timer and, within this time, attempts to submit the anchor block for the current period by satisfying specific direct commit conditions.
[0035] If the submission is successful before the timeout, it signifies the successful completion of this cycle. The system then calculates the node reputation score based on the submitted anchor blocks and determines the set of leader nodes for the next cycle, thus entering a new optimistic execution path and forming a performance-optimized operating cycle.
[0036] In S103, further, if the anchor block is not successfully submitted within the preset timeout period, it indicates that the network may experience severe latency or some leader nodes may be abnormal. At this point, to ensure system activity, the protocol automatically switches to the pessimistic execution path. This path proceeds in waves, with each wave consisting of two rounds: hierarchical reliable broadcast and consensus broadcast. In the consensus broadcast round, all nodes invoke the global random coin mechanism to participate in the election, producing an unpredictable but unanimously recognized temporary leader node. The block generated by this node serves as a new candidate block.
[0037] Finally, through S104, the new candidate blocks generated in the pessimistic path are subject to final state adjudication. The core of this process is determining their causal dependency on the original anchor block in the optimistic path. If the original anchor block can be indirectly referenced through a reference path in the directed acyclic graph, it proves that the original anchor block actually meets the commit conditions. In this case, the system will commit the original anchor block, discard the pessimistic path, and directly roll back to the optimistic execution path, achieving rapid recovery. If the new candidate block cannot reference the original anchor block, it is safely assumed that no node will commit the original anchor block. In this situation, the node promotes the new candidate block to a new official anchor block, recalculates the reputation score based on this new anchor and its history, determines a new set of leader nodes, and starts a completely new optimistic execution path from the new starting point. This adjudication and switching mechanism is crucial for the system to maintain final liveness and safely roll back to a high-performance state under extreme environments.
[0038] Optionally, the process of obtaining the reputation score and the set of leader nodes includes: Once the anchor block of the current consensus period is submitted, the leader nodes with the determined order within the current consensus period are traversed. For each leader node traversed, if the generated block references a block from the previous round, a positive score is added to the reputation score of the node corresponding to the leader node, so as to accumulate the final reputation score of each node. Based on the final reputation scores of all nodes in this cycle, a predetermined number of nodes with the highest rankings are selected to form the leader node set for the next consensus cycle.
[0039] Specifically, the reputation scoring mechanism in this embodiment is the core basis for the selection of leader nodes, and its calculation process has clear triggering times and rules.
[0040] In each consensus epoch, the nodes participating in the consensus maintain a set of reputation scores to reflect their historical performance in the current consensus epoch. Specifically, when entering a consensus epoch, the system initializes the corresponding reputation scores for all nodes, with the initial values all being zero.
[0041] Once the anchor block for a consensus cycle is successfully submitted, the nodes iterate through the leader nodes whose order has been determined within that cycle. For each leader node, if its generated block references a block from a previous round, the node is considered to have performed well in the consensus process, and its reputation score is increased by one unit. This process accumulates the scores of nodes' behavior throughout the entire consensus cycle, resulting in the final reputation score for each node in that cycle. After calculating the reputation score for the current consensus cycle, the system determines the set of pre-selected leader nodes for the fast execution path in the next consensus cycle based on these final reputation scores.
[0042] Specifically, each node sorts nodes based on the reputation scores of all nodes within the current consensus period; when multiple nodes have the same reputation score, a pre-agreed deterministic rule is used for sorting to ensure consistency of sorting results among different nodes.
[0043] After sorting, several top-ranked nodes are selected as pre-selected leader nodes for the next consensus cycle. The core idea of the above leader node selection strategy is that nodes that can generate and broadcast blocks in a timely manner and be successfully referenced by other nodes within a consensus cycle usually have lower communication latency and higher participation.
[0044] By continuously scoring the performance of these nodes in the historical consensus process and prioritizing nodes with higher reputation scores as leader nodes in subsequent consensus cycles, the probability of nodes with large communication latency or abnormal behavior being selected as leader nodes can be effectively reduced. Therefore, in subsequent consensus execution, the system is more likely to be driven by nodes with fast response times and high stability, thereby improving overall consensus efficiency and reducing block submission latency.
[0045] Optionally, the execution process of the optimistic execution path includes: In the optimistic execution path, the consensus process is advanced in rounds, and each node propagates blocks based on a directed acyclic graph structure; The nodes in the set of leader nodes are arranged in a predetermined order and serve as leader nodes in their respective designated rounds. The blocks generated by the leader nodes constitute the leader blocks for each round. When the preset direct commit conditions are met, the corresponding leader block and all historical leader blocks and their corresponding ancestor blocks that have a path relationship but have not yet been committed are committed. Set a timeout timer. If the anchor block for the current consensus period is successfully submitted before the timeout, the reputation score and leader node pre-selection are performed based on the anchor block.
[0046] Specifically, in this embodiment, the consensus process is organized and advanced in rounds within the optimistic execution path. All participating nodes propagate and reference blocks in parallel based on a directed acyclic graph (DAG) data structure.
[0047] In the leader node's round, each node uses the Reliable Broadcast (RBC) protocol to propagate its blocks to ensure complete consistency in message delivery; in the non-leader node's round, each node uses the Consistent Broadcast (CBC) protocol to propagate its blocks. The block proposed by the last pre-elected leader node in this consensus cycle is used as the temporary anchor block for that cycle.
[0048] The nodes in the pre-selected set of leader nodes take turns assuming leadership responsibilities in designated rounds according to a predetermined order. The blocks generated by a leader node in its round are specially marked as the leader blocks for that round.
[0049] This embodiment sets a direct commit condition. Once this condition is met, the node will not only directly commit the leader block, but will also backtrack along the reference path in the DAG to recursively commit all historical leader blocks that have a causal dependency on it but have not yet been committed.
[0050] At the same time, the node starts a preset timeout timer. If the final target block of the current consensus cycle is successfully committed before the timer expires, the cycle ends.
[0051] Subsequently, based on the complete cycle history encapsulated in the identified anchor block, a reputation score is calculated and a new set of leader nodes is pre-selected for the next cycle, thus initiating a new round of optimistic execution path.
[0052] Furthermore, the submission process for the anchor block includes: For the leader block generated in round r, if a node receives the first message of at least 2f+1 blocks in round r+1, and all of these blocks reference the leader block of round r, then the node directly submits the leader block of round r; where r is the round number. Alternatively, if a node delivers at least f+1 blocks in round r+1 that all reference the leader block of round r, then the node directly submits the leader block of round r; where r is the round number. After directly committing the leader block, the node backtracks along the local directed acyclic graph, in turn indirectly committing all uncommitted historical leader blocks reachable through reference paths, until it encounters a committed leader block.
[0053] Specifically, for any non-faulty node, when it receives the first message of at least 2f+1 corresponding blocks in round r+1, and all of these blocks reference the leader block of round r, then the node directly commits the leader block of round r. Among these 2f+1 blocks, at least f+1 originate from non-faulty nodes. The block content carried in the first message sent by a non-faulty node is guaranteed to be ultimately deliverable. Furthermore, since each block in round r+1 references at least n blocks in round r... Given f blocks, for any leader block in round r+2 or higher, there exists at least one path from that block to the leader block in round r, thus ensuring the security of committing the leader block in round r. In addition to the above commit conditions, a node can also directly commit the leader block when it receives at least f+1 blocks in round r+1 that all reference the leader block in round r.
[0054] Once the leader block is directly committed, the node will backtrack along its local DAG and indirectly commit all historical leader blocks with which it has a path relationship, until it encounters a committed leader block. For example... Figure 2 As shown, based on the accumulated reputation scores of each node within consensus period e, the nodes p2 and p3 with the highest reputation scores are determined as the pre-selected leader nodes in the optimistic execution path of consensus period e+1.
[0055] Optionally, a synchronization constraint mechanism is also included before the optimistic execution path enters the next consensus cycle; The synchronization constraint mechanism specifically includes: When a node submits the anchor block for the current consensus period before the timeout, it broadcasts a submission message. When a node receives at least f+1 commit messages for the same anchor block, it broadcasts its own commit message. Once a node has collected at least 2f+1 commit messages, it aggregates the commit messages into a commit certificate and broadcasts it. Once a node obtains the submission certificate, it enters the optimistic execution path of the next consensus cycle and broadcasts a new block. If the submission certificate is not obtained before the timeout timer expires, a forced switch to the pessimistic execution path will be initiated.
[0056] Specifically, to further ensure system security, this embodiment introduces an additional constraint mechanism in the optimistic execution path. When a node successfully commits the anchor block of the previous consensus cycle before the timeout expires, the node broadcasts the corresponding commit message to other nodes. Any non-faulty node, after receiving at least f+1 corresponding commit messages, will also broadcast the same commit message. After collecting at least 2f+1 commit messages, a node aggregates them to form a commit certificate (CC) and broadcasts it. A node only enters the optimistic execution path of the next consensus cycle and broadcasts its new block after obtaining the commit certificate. If a commit certificate is not obtained within the timeout period, the node switches to the pessimistic execution path of the previous consensus cycle, even if the anchor block of that cycle has already been committed by some nodes. Furthermore, if a node enters a new consensus cycle by committing the anchor block of the previous cycle, its first broadcast block in the new cycle must include the commit certificate.
[0057] The aforementioned constraint mechanism serves the purpose that if a node has not yet committed the anchor block of the previous consensus cycle, it can still complete the commit by receiving at least f+1 commit messages or a complete commit certificate. When the anchor block does not yet exist in the local DAG, the node will request the missing block from other nodes. Since at least one non-faulty node has committed and holds the anchor block, the request will inevitably be responded to, thus ensuring that the node can complete the commit process. Simultaneously, to prevent security issues caused by some nodes advancing along optimistic execution paths while others advance along pessimistic execution paths, this application stipulates that a node can only enter a new optimistic execution path after obtaining a commit certificate. Since the commit certificate contains at least f+1 commit messages from non-faulty nodes, any non-faulty node will broadcast the corresponding commit information after receiving at least f+1 commit messages, thus ensuring that all non-faulty nodes eventually obtain commit certificates and synchronously enter the optimistic execution path of the next consensus cycle.
[0058] It should be noted that in the optimistic execution path, depending on whether a timeout is triggered, there are two possible scenarios: (1) When a temporary anchor block is successfully delivered and submitted before the timeout period expires, the temporary anchor block is confirmed as a formal anchor and submitted immediately. Subsequently, each node generates a list of leader nodes for the next consensus cycle according to the leader node pre-selection rules and enters the optimistic execution path of the next cycle.
[0059] (2) If the anchor block is not delivered before the timeout expires, the node switches to the pessimistic path. Regardless of whether the system switches to the pessimistic path, each node must receive at least nf blocks in the last round of the optimistic execution path of the current consensus cycle before proceeding to the next stage, in order to ensure the consistency of the system state.
[0060] Optionally, the pessimistic execution path steps specifically include: Advancement is based on waves, with each wave consisting of a hierarchical reliable broadcast round and a consistent broadcast round; Once a node has delivered at least nf blocks of level 2, it broadcasts the new blocks via the consensus broadcast protocol to advance to the next round; where n is the total number of nodes. In the consensus broadcast round, each node generates and broadcasts the block and global random coin parameter signature; At the end of the wave, each node, based on the output of the global random coin, jointly elects a temporary leader node, and the block generated by the temporary leader node in the corresponding round is used as the new candidate block.
[0061] Furthermore, determining whether the new candidate block can indirectly reference the anchor block includes: Determine whether the temporary leader node can indirectly reference the anchor block in the optimistic execution path of the current consensus cycle through a directed path; if it exists, it is determined that it can be indirectly referenced; if it does not exist, it is determined that it cannot be indirectly referenced.
[0062] Specifically, when an anchor block in the optimistic execution path of the current consensus cycle fails to meet the submission conditions within a preset timeout period, the protocol switches to the pessimistic execution path corresponding to that consensus cycle to maintain system activity in an asynchronous network environment. The pessimistic execution path progresses in waves, each consisting of two consecutive rounds: a Graded Reliable Broadcast (GRBC) round and a Consensus Broadcast (CBC) round, corresponding to even-numbered and odd-numbered rounds, respectively. Once a node has delivered at least nf blocks of grade 2, it broadcasts a new block via the CBC protocol to advance to the next round. In each wave, blocks generated in odd-numbered rounds carry the input parameters of the Global Perfect Coin (GPC) function, used to elect a leader node in the pessimistic path at the end of that round.
[0063] In the pessimistic execution path, this application introduces two key design elements: a temporary leader node and a rollback mechanism. The design principle is as follows: After the GPC component outputs a leader node, each node first verifies whether the block corresponding to that leader node has been successfully delivered at level 2. In the GradedDAG protocol, once this condition is met, the leader block and all its ancestor blocks can be directly committed.
[0064] In the pessimistic execution path of this application, the elected pessimistic leader node does not immediately join the leader block commit queue, but is instead treated as a temporary leader node. Each node then determines whether the temporary leader node can indirectly reference the temporary anchor block in the optimistic execution path of the current consensus cycle through a directed path. Depending on whether the temporary leader node can indirectly reference the anchor block, the following two cases are handled: Scenario 1: The temporary leader node can indirectly reference the anchor block in the optimistic execution path. This indicates that some non-faulty nodes may have already committed the anchor block. To ensure all nodes reach consensus on the anchor block, the temporary leader node is treated as a normal block and the current pessimistic execution path is discarded. At this point, the node rolls back to the optimistic execution path. If a node has not yet committed the anchor block, it completes the commit at this stage and subsequently enters the optimistic execution path for the next consensus cycle.
[0065] like Figure 3 As shown, since block L7 can indirectly reference the anchor block L6 of the optimistic execution path in consensus cycle e+1, block L7 is treated as a normal block, the anchor block L6 is committed, and round 2 (w+5) is regarded as the first round of the optimistic execution path in consensus cycle e+2.
[0066] Scenario 2: The temporary leader node cannot indirectly reference the anchor block in the optimistic execution path. This situation indicates that no non-faulty node has committed the anchor block. According to the arbitral intersection property, if a non-faulty node commits the anchor block La in round i, it must observe at least f+1 blocks referencing La in round i+1; at the same time, since each block in round i+2 and thereafter must reference at least n blocks from the previous round... Given *f* blocks, any block generated in round *k* ≥ *i* + 2 should have a path pointing to *La*. Therefore, if the temporary leader node cannot indirectly reference the anchor block, it can be safely inferred that the anchor block has not been committed by any node. In this case, the temporary leader node is promoted to the new anchor block. Subsequently, the system recalculates the reputation score of the current consensus cycle based on the causal history of the new anchor block and determines the set of pre-selected leader nodes in the optimistic execution path of the next consensus cycle accordingly. The protocol then enters the optimistic execution path of the next consensus cycle.
[0067] like Figure 3 As shown, since block L4 cannot indirectly reference anchor block L2, it is promoted to the new anchor block, and based on the updated reputation score, blocks L5 and L6 are selected as pre-selected leader nodes in the optimistic execution path of the next consensus cycle. The system continues to advance subsequent block broadcasting and consensus execution.
[0068] To evaluate the performance of the proposed Mako protocol, it was compared with three representative Byzantine fault-tolerant consensus protocols based on Directed Acyclic Graphs (DAGs): Bullshark, Tusk, and GradedDAG. Tusk and GradedDAG were tested using asynchronous network models, while Bullshark was tested with its partially synchronous configuration. To minimize the impact of implementation differences and ensure fairness and consistency in the comparative experiments, all protocols were implemented in Golang within a unified experimental framework. The experiments primarily evaluated two performance metrics: throughput and end-to-end latency. Throughput was defined as the number of transactions successfully committed per second; end-to-end latency was defined as the time elapsed between a client sending a transaction request and the transaction being successfully committed by a node. Each experimental data point was obtained by averaging three independent experiments, and the error bar represents one standard deviation. When the variance of the experimental results is small, the error bar may not be obvious in the graph.
[0069] Figure 4 and Figure 6 This paper demonstrates the performance of the proposed reputation-based, high-efficiency asynchronous DAG consensus protocol (Mako protocol) in committees of 10 and 16 nodes, under fault-free conditions and with nodes distributed across different geographical regions. Overall, Mako outperforms the comparative protocols in both throughput and end-to-end latency. For example, in a 10-node committee, Mako's peak throughput is approximately 95,000 transactions per second, while Tusk, GradedDAG, and Bullshark's peak throughputs are approximately 63,000, 74,000, and 68,000 transactions per second, respectively. Furthermore, Mako's end-to-end latency remains below 500 milliseconds until the throughput reaches approximately 86,000 transactions per second; even at input rates approaching 95,000 transactions per second, its latency remains below 1 second. Before the system reaches saturation, Mako's latency is approximately 76.6% of GradedDAG, 65.4% of Bullshark, and 38.0% of Tusk. The main reason for Tusk's higher latency is that it requires at least nine communication steps to commit a block, while Bullshark requires six. In contrast, Mako and GradedDAG can both complete block commits within four communication steps. Although Mako and GradedDAG have the same number of communication steps, Mako still reduces end-to-end latency by approximately 24% compared to GradedDAG. This performance improvement is mainly due to Mako's fast path design: during leader selection, nodes with higher network latency or geographically distant locations are identified as unfavorable nodes, thus reducing their probability of being selected as leaders; while nodes with better network conditions and faster response times are selected as leaders more frequently, effectively reducing block commit latency.
[0070] Figure 6 and Figure 7 This paper demonstrates performance evaluations of committees with 10 and 16 nodes in the presence of Byzantine faulty nodes, with f Byzantine nodes present in the system. All Byzantine nodes are controlled by the same attacker whose goal is to prevent normal block submissions. As shown in the figure, compared to the fault-free scenario, all protocols experience increased block submission latency when Byzantine nodes are present. In the fault-free scenario, the leader node is always honest, and each protocol can rely on the 2f+1 fastest nodes to complete block submissions. However, with f Byzantine nodes, if the leader node in a certain round is Byzantine, the protocol must wait for an honest leader node to emerge in subsequent rounds to complete the block submission, thus increasing the submission latency. In a system with 10 nodes and 3 Byzantine nodes, compared to the ideal scenario, Tusk's block submission latency increases by approximately 1.2 seconds, while Bullshark and GradedDAG's latency increases by approximately 0.7 seconds each. In contrast, Mako experiences the least performance degradation, with only an increase in submission latency of approximately 0.5 seconds. In terms of peak throughput, Mako still outperforms other comparable protocols. It's worth noting that while Mako may be affected by Byzantine nodes in the early stages of protocol implementation, this impact gradually diminishes as the consensus cycle progresses: Byzantine nodes are no longer elected as leader nodes, and the leadership role is gradually assumed by nodes actively participating in consensus. Therefore, the long-term impact of Byzantine nodes on Mako's throughput and latency is relatively limited.
[0071] Reference Figure 8 This application also provides an asynchronous consensus system based on reputation scoring and dual-path switching, including: The reputation scoring module 810 is used to calculate the reputation score based on the behavior of each node in the current consensus cycle, and to determine the set of leader nodes for the next consensus cycle based on the reputation score, so as to enter the optimistic execution path. The optimistic path module 820 is used to lead the consensus process through the nodes in the leader node set in the optimistic execution path, and to pre-submit the anchor block of the current consensus cycle within a preset timeout period in order to enter the optimistic execution path of the next consensus cycle. The pessimistic path module 830 is used to switch to the pessimistic execution path if the anchor block is not successfully submitted within the timeout period, and to promote consensus by electing a temporary leader node through a global random coin mechanism to generate a new candidate block. The judgment module 840 is used to determine whether the new candidate block can indirectly reference the anchor block: if yes, the anchor block is submitted to roll back to the optimistic execution path; if no, the new candidate block is promoted to the updated anchor block, the reputation score is recalculated based on the updated anchor block, and a new set of leader nodes is determined to start a new optimistic execution path.
[0072] Optionally, the execution process of the optimistic execution path includes: In the optimistic execution path, the consensus process is advanced in rounds, and each node propagates blocks based on a directed acyclic graph structure; The nodes in the set of leader nodes are arranged in a predetermined order and serve as leader nodes in their respective designated rounds. The blocks generated by the leader nodes constitute the leader blocks for each round. When the preset direct commit conditions are met, the corresponding leader block and all historical leader blocks and their corresponding ancestor blocks that have a path relationship but have not yet been committed are committed. Set a timeout timer. If the anchor block for the current consensus period is successfully submitted before the timeout, the reputation score and leader node pre-selection are performed based on the anchor block.
[0073] Optionally, the process of obtaining the reputation score and the set of leader nodes includes: Once the anchor block of the current consensus period is submitted, the leader nodes with the determined order within the current consensus period are traversed. For each leader node traversed, if the generated block references a block from the previous round, a positive score is added to the reputation score of the node corresponding to the leader node, so as to accumulate the final reputation score of each node. Based on the final reputation scores of all nodes in this cycle, a predetermined number of nodes with the highest rankings are selected to form the leader node set for the next consensus cycle.
[0074] Optionally, the submission process for the anchor block includes: For the leader block generated in round r, if a node receives the first message of at least 2f+1 blocks in round r+1, and all of these blocks reference the leader block of round r, then the node directly submits the leader block of round r. Alternatively, if a node delivers at least f+1 blocks in round r+1 that all reference the leader block of round r, then the node directly submits the leader block of round r. After directly committing a leader block, the node backtracks along the local directed acyclic graph, in turn indirectly committing all uncommitted historical leader blocks reachable by reference paths, until it encounters a committed leader block.
[0075] Optionally, the pessimistic execution path steps specifically include: Advancement is based on waves, with each wave consisting of a hierarchical reliable broadcast round and a consistent broadcast round; Once a node has delivered at least nf blocks of level 2, it broadcasts new blocks via the consensus broadcast protocol to advance to the next round. In the consensus broadcast round, each node generates and broadcasts a block that includes the parameters for invoking the global random coin. At the end of the wave, each node, based on the output of the global random coin, jointly elects a temporary leader node, and the block generated by the temporary leader node in the corresponding round is used as the new candidate block.
[0076] Optionally, a synchronization constraint mechanism is also included before the optimistic execution path enters the next consensus cycle; The synchronization constraint mechanism specifically includes: When a node submits the anchor block for the current consensus period before the timeout, it broadcasts a submission message. A node broadcasts a commit message after receiving at least f+1 commit messages for the same anchor block. Once a node has collected at least 2f+1 commit messages, it aggregates the commit messages into a commit certificate and broadcasts it. Once a node obtains the submission certificate, it enters the optimistic execution path of the next consensus cycle and broadcasts a new block. If the submission certificate is not obtained before the timeout timer expires, a forced switch to the pessimistic execution path will be initiated.
[0077] Optionally, determining whether the new candidate block can indirectly reference the anchor block includes: Determine whether the temporary leader node can indirectly reference the anchor block in the optimistic execution path of the current consensus cycle through a directed path; if it exists, it is determined that it can be indirectly referenced; if it does not exist, it is determined that it cannot be indirectly referenced.
[0078] Optionally, under the optimistic execution path, the leader node propagates its blocks using the Reliable Broadcast (RBC) protocol in its round; the non-leader node propagates its blocks using the Consistent Broadcast (CBC) protocol in its round.
[0079] Reference Figure 9Based on the methods in the above embodiments, this application provides an electronic device that may include: a processor 910, a communications interface 920, a memory 930, and a communication bus 940. The processor 910, communications interface 920, and memory 930 communicate with each other via the communication bus 940. The processor 910 can call logical instructions in the memory 930 to execute the methods in the above embodiments.
[0080] Furthermore, the logical instructions in the aforementioned memory 930 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.
[0081] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.
[0082] Based on the methods in the above embodiments, this application provides a computer program product that, when run on a processor, causes the processor to execute the methods in the above embodiments.
[0083] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.
[0084] The method steps in this application embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.
[0085] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).
[0086] It is understood that the various numerical designations used in the embodiments of this application are merely for the convenience of description and are not intended to limit the scope of the embodiments of this application.
[0087] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. An asynchronous consensus method based on reputation scoring and dual-path switching, characterized in that, Running on an asynchronous Byzantine fault-tolerant distributed system, the distributed system comprising at least 3f+1 nodes, where f is the upper limit of the number of fault-tolerant nodes, the method includes: A reputation score is calculated based on the behavior of each node in the current consensus cycle, and the set of leader nodes for the next consensus cycle is determined based on the reputation score to enter the optimistic execution path of the next consensus cycle. In the optimistic execution path, the consensus process is advanced by the nodes in the leader node set, and the anchor block of the current consensus cycle is pre-submitted within a preset timeout period in order to enter the optimistic execution path of the next consensus cycle. If the anchor block is not successfully submitted within the timeout period, the pessimistic execution path is switched to, and a temporary leader node is elected through a global random coin mechanism to advance consensus and generate a new candidate block. Determine whether the new candidate block can indirectly reference the anchor block; if yes, submit the anchor block to roll back to the optimistic execution path; if no, promote the new candidate block to the updated anchor block, recalculate the reputation score based on the updated anchor block, and determine the leader node set for the next consensus cycle to start a new optimistic execution path.
2. The asynchronous consensus method based on reputation scoring and dual-path switching according to claim 1, characterized in that, The execution process of the optimistic execution path includes: In the optimistic execution path, the consensus process is advanced in rounds, and each node propagates blocks based on a directed acyclic graph structure; The nodes in the set of leader nodes are arranged in a predetermined order and serve as leader nodes in their respective designated rounds. The blocks generated by the leader nodes constitute the leader blocks for each round. When the preset direct commit conditions are met, the corresponding leader block and all historical leader blocks and their corresponding ancestor blocks that have a path relationship but have not yet been committed are committed. Set a timeout timer. If the anchor block for the current consensus period is successfully submitted before the timeout, the reputation score and leader node pre-selection are performed based on the anchor block.
3. The asynchronous consensus method based on reputation scoring and dual-path switching according to claim 1, characterized in that, The process of obtaining the reputation score and the set of leader nodes includes: Once the anchor block of the current consensus period is submitted, the leader nodes with the determined order within the current consensus period are traversed. For each leader node traversed, if the generated block references a block from the previous round, a positive score is added to the reputation score of the node corresponding to the leader node, so as to accumulate the final reputation score of each node. Based on the final reputation scores of all nodes in this cycle, a predetermined number of nodes with the highest rankings are selected to form the leader node set for the next consensus cycle.
4. The asynchronous consensus method based on reputation scoring and dual-path switching according to claim 1, characterized in that, The submission process for the anchor block includes: For the leader block generated in round r, when a node receives the first message of at least 2f+1 blocks in round r+1, and the blocks corresponding to the 2f+1 first messages all reference the leader block of round r, the node directly submits the leader block of round r; where r is the round number. Alternatively, if a node delivers at least f+1 blocks in round r+1 that all reference the leader block of round r, then the node directly submits the leader block of round r. After directly committing a leader block, the node backtracks along the local directed acyclic graph, in turn indirectly committing all uncommitted historical leader blocks reachable by reference paths, until it encounters a committed leader block.
5. The asynchronous consensus method based on reputation scoring and dual-path switching according to claim 1, characterized in that, The specific steps of the pessimistic execution path include: Advancement is based on waves, with each wave consisting of a hierarchical reliable broadcast round and a consistent broadcast round; Once a node has delivered at least nf blocks of level 2, it broadcasts the new blocks via the consensus broadcast protocol to advance to the next round; where n is the total number of nodes. In the consensus broadcast round, each node generates and broadcasts a block that includes the parameters for invoking the global random coin. At the end of the wave, each node, based on the output of the global random coin, jointly elects a temporary leader node, and the block generated by the temporary leader node in the corresponding round is used as the new candidate block.
6. The asynchronous consensus method based on reputation scoring and dual-path switching according to claim 2, characterized in that, Before the optimistic execution path to enter the next consensus cycle, a synchronization constraint mechanism is also included; The synchronization constraint mechanism specifically includes: When a node submits the anchor block for the current consensus period before the timeout, it broadcasts a submission message. A node broadcasts the commit message after receiving at least f+1 identical commit messages for the same anchor block; Once a node has collected at least 2f+1 identical commit messages, it aggregates the commit messages into a commit certificate and broadcasts it. Once a node obtains the submission certificate, it enters the optimistic execution path of the next consensus cycle and broadcasts a new block. If the submission certificate is not obtained before the timeout timer expires, a forced switch to the pessimistic execution path will be initiated.
7. The asynchronous consensus method based on reputation scoring and dual-path switching according to claim 1, characterized in that, The step of determining whether the new candidate block can indirectly reference the anchor block includes: Determine whether the temporary leader node can indirectly reference the anchor block in the optimistic execution path of the current consensus cycle through a directed path; if it exists, it is determined that it can be indirectly referenced; if it does not exist, it is determined that it cannot be indirectly referenced.
8. The asynchronous consensus method based on reputation scoring and dual-path switching according to any one of claims 1 to 7, characterized in that, Under the optimistic execution path, the leader node uses the Reliable Broadcast (RBC) protocol to propagate its blocks in its round; Non-leader nodes propagate their blocks using the Consistency Broadcast (CBC) protocol within their respective rounds.
9. An asynchronous consensus system based on reputation scoring and dual-path switching, characterized in that, include: The reputation scoring module is used to calculate the reputation score based on the behavior of each node in the current consensus cycle, and to determine the set of leader nodes for the next consensus cycle based on the reputation score, so as to enter the optimistic execution path. The optimistic path module is used to lead the consensus process through the nodes in the leader node set in the optimistic execution path, and to pre-submit the anchor block of the current consensus cycle within a preset timeout period in order to enter the optimistic execution path of the next consensus cycle. The pessimistic path module is used to switch to the pessimistic execution path if the anchor block is not successfully submitted within the timeout period, and to promote consensus by electing a temporary leader node through a global random coin mechanism to generate a new candidate block. The judgment module is used to determine whether the new candidate block can indirectly reference the anchor block: if so, the anchor block is submitted to roll back to the optimistic execution path. If not, the new candidate block is promoted to the updated anchor block, the reputation score is recalculated based on the updated anchor block, and a new set of leader nodes is determined to initiate a new optimistic execution path.
10. An electronic device, characterized in that, include: At least one memory for storing computer programs; At least one processor is configured to execute a program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to perform the method as described in any one of claims 1-8.