A dag type asynchronous byzantine fault tolerance consensus method based on a parallel double path architecture

Abstract

The application relates to the fields of blockchains and distributed consensus technologies, and provides a DAG type asynchronous Byzantine fault-tolerant consensus method PDAG-BFT based on a parallel double-path architecture. The method constructs a consensus architecture with optimistic paths and pessimistic paths advancing in parallel to solve the problems of high delay and resource waste of a traditional DAG type BFT protocol in an asynchronous network under network fluctuation, high load and path rollback. Each copy jointly maintains a DAG account book, and blocks reach State0, State1 and State2 states through GCBC two-stage broadcasting; the optimistic path submits State2 leader blocks and their ancestors when the network is good, and the pessimistic path determines the leader through delayed election and threshold signature only when the optimistic path is blocked. The two paths share the DAG and broadcasting results, and determine the submission object in combination with a HelpMsg and an ABA protocol, so that the delay is reduced, redundant communication is reduced, and robustness is improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain and distributed systems technology, specifically a DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture. Background Technology

[0002] The Byzantine Fault Tolerance (BFT) consensus protocol is a core component of blockchain systems, responsible for ensuring that all honest nodes reach consensus on transaction order and ledger state in a distributed environment with malicious nodes, faulty nodes, or network anomalies. As blockchain systems are increasingly used in scenarios such as financial clearing, supply chain collaboration, digital government, the Internet of Things (IoT), and cross-domain data sharing, the system needs to simultaneously meet security, activity, high throughput, and low confirmation latency under conditions of large-scale replication and high transaction load.

[0003] Regarding network models, some synchronous BFT protocols typically exhibit low latency under favorable network conditions. However, when network latency fluctuates drastically or the leader is attacked, the protocol often relies on timeout and view-switching mechanisms to maintain liveness. Frequent view-switching incurs significant waiting and state synchronization overhead. Asynchronous BFT protocols are better suited to unpredictable network environments, but they usually require complex components such as reliable broadcasting, asynchronous binary consensus, randomization mechanisms, or multi-value consensus, resulting in higher communication rounds and acknowledgment latency.

[0004] In recent years, BFT consensus protocols based on Directed Acyclic Graphs (DAGs) have improved system throughput by decoupling transaction propagation from transaction ordering, enabling multiple replicas to create and propagate blocks in parallel. However, existing DAG-based asynchronous BFT protocols still generally employ a serialized rollback strategy for liveness assurance, i.e., executing the optimistic path first and only initiating the pessimistic path after the optimistic path times out or fails. This design can reduce some overhead when the network is in good condition, but it has significant drawbacks in scenarios with frequent network fluctuations, DDoS attacks, or leader failure: First, each rollback requires a full timeout period, leading to a significant increase in end-to-end confirmation latency; second, the delayed initiation of the pessimistic path requires the system to wait additionally for broadcasting, election, and adjudication processes after the optimistic path fails; third, under high load conditions, repeated broadcasting and path switching waste resources and reduce the system's available throughput.

[0005] Therefore, there is an urgent need for a consensus method that can simultaneously utilize the parallel propagation capability of DAG and the dual-path liveness guarantee capability under an asynchronous network model. This method can reduce the waiting overhead caused by serial path switching, reduce redundant communication of pessimistic paths, and improve the robustness of the system under network fluctuations and failure scenarios while ensuring security and liveness. Summary of the Invention

[0006] The purpose of this invention is to provide a DAG-based asynchronous Byzantine Fault Tolerant (BFT) consensus method based on a parallel dual-path architecture. This aims to address the problems in existing DAG-based asynchronous BFT protocols, such as long path switching wait times, delayed pessimistic path initiation, redundant consumption of broadcast resources, and high confirmation latency in complex network environments caused by the serialized backoff strategy. This invention significantly reduces consensus latency by initiating optimistic and pessimistic paths in parallel in each round, allowing both paths to share the same DAG structure and the same GCBC broadcast result. Furthermore, it combines a delayed election mechanism, a HelpMsg mechanism, and an ABA final decision mechanism, thereby ensuring protocol security and liveness.

[0007] This invention is achieved through the following technical solution:

[0008] A DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture, the method comprising:

[0009] Step 1: System Initialization and DAG Ledger Construction. In an asynchronous distributed system containing n replicas, each replica has a unique identity, public key, and private key. The system establishes a PKI and adopts a collision-resistant hash function and a threshold signature scheme. Each replica jointly maintains a DAG-style block ledger DAG_i[r]. The block structure includes a block digest, a round, a parent block set, a creator author, a transaction set txs, a state, and a signature.

[0010] Step 2: Parallel Dual-Path Launch. In each consensus round, both the optimistic and pessimistic paths are launched simultaneously. The optimistic path is used to quickly submit the optimistic leader block when the network is good, while the pessimistic path is used to ensure protocol termination if the optimistic path fails. Both paths share the same DAG ledger structure, the same GCBC broadcast instance, and block state information.

[0011] Step 3: GCBC Two-Phase Block Broadcast. Each replica creates the current round's block and references at least 2f+1 blocks from the previous round as parent blocks. After block generation, two consecutive consistent broadcasts are performed via the GCBC broadcast mechanism: the first broadcast collects at least 2f+1 Vote messages, updates the block state to State1, and delivers it to the local DAG; the second broadcast collects at least 2f+1 Ready messages, aggregates them to form the Done certificate, and updates the block state to State2.

[0012] Step 4, Optimistic Path Commit. In each round, an optimistic leader is determined using polling rules. Replicas start a timer and wait for the optimistic leader block to reach State 2. If the optimistic leader block reaches State 2 before or at the timer's expiration, the optimistic leader block and its ancestor blocks are directly committed, and the round progresses. If the fast commit condition is not met, the HelpMsg mechanism and the ABA final decision process are triggered.

[0013] Step 5: Delayed Election for the Pessimistic Path. At the start of each round, the replica starts a delayed election thread and waits for Δ / 2 time. If the optimistic path has advanced a round during the waiting period, the broadcast of the pessimistic path Elect message is skipped; if the current round has not advanced, the replica broadcasts an Elect message carrying the threshold signature share. After collecting no less than 2f+1 Elect messages, the threshold signatures are aggregated and the pessimistic leader is determined through a hash mapping.

[0014] Step 6: HelpMsg Mechanism and ABA Final Decision. When the optimistic path fails to commit quickly, each replica constructs and broadcasts a HelpMsg message based on the state of the optimistic leader block in its local DAG. After collecting at least 2f+1 HelpMsg messages, it determines whether to commit directly or initiate the ABA protocol based on the distribution of State0, State1, and State2 in the messages. An ABA output of 1 commits the optimistic leader block, while an ABA output of 0 commits the pessimistic leader block.

[0015] Step 7: Block Commit and Execution. The replica traces back the ancestor blocks in the DAG based on the finally committed leader block, generating a deterministic sequence of leader blocks and transaction blocks. Transactions are executed in sequence, and the execution results are persisted. Then, the process moves to the next round.

[0016] The beneficial effects of this invention are as follows: By running the optimistic path and pessimistic path simultaneously through a parallel dual-path architecture, the path switching overhead of waiting for the optimistic path to fail before starting the pessimistic path, which is common in traditional serial dual-path schemes, is eliminated; by sharing the same DAG structure and GCBC broadcast results, the pessimistic path avoids repeatedly executing additional broadcast processes, reducing communication costs; through a delayed election mechanism, the pessimistic path election message is skipped when the optimistic path can commit quickly, reducing redundancy overhead in fault-free scenarios; through the HelpMsg mechanism and the ABA final decision mechanism, it is ensured that the optimistic path and the pessimistic path will not commit conflicting blocks in the same round; and through the DAG parent reference relationship and the leader block sequence backtracking rule, the block sequence of different honest replicas is ensured to be consistent. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0018] Figure 1 This is a schematic diagram of the overall process of the DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture provided in this embodiment of the invention.

[0019] Figure 2 This is a schematic diagram of the two-stage block broadcast state transition of GCBC provided in an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the overall execution flow of the optimistic path provided in an embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of the processing flow of the optimistic leader block in State2, State1 and State0 states provided in an embodiment of the present invention;

[0022] Figure 5 This is a schematic diagram of the pessimistic path delayed election and submission process provided in an embodiment of the present invention;

[0023] Figure 6 This is a schematic diagram of the HelpMsg mechanism and the ABA final adjudication process provided in this embodiment of the invention;

[0024] Figure 7 This is a comparative analysis of the throughput and latency performance of the embodiments of the present invention and existing designs in low-load scenarios; Figure 8 This is a comparative analysis of the throughput and latency performance of the embodiments of the present invention and existing designs under high load scenarios;

[0025] Figure 9 This is a comparative analysis of the throughput and latency performance of the embodiments of the present invention and existing designs in DDoS network confrontation scenarios. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0027] like Figures 1 to 6 As shown, the DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture provided in this embodiment includes the following steps:

[0028] Step 1: System initialization and DAG ledger construction.

[0029] This invention considers an asynchronous distributed system consisting of n replicas, where at most f Byzantine replicas exist, and satisfies... Each copy It has a unique identity and public key. and private key The public key is used for identity verification and signature authentication, while the private key is kept only by its corresponding copy. The system pre-establishes a Public Key Infrastructure (PKI) to enable each copy to verify the signatures of other copies. The system employs a collision-resistant hash function. Generate fixed-length digests for blocks and messages, and use a threshold signature scheme to aggregate signatures for Done certificates and election messages.

[0030] Each replica maintains a DAG-style block ledger locally. The block structure is Where digest is the block digest, round is the round to which the block belongs, parent is the set of parent blocks from the previous round referenced by the current block, author is the public key of the block creator, txs is the set of transactions packaged in the block, state is the block broadcast state, and sign is the signature of the block creator.

[0031] Step 2: Parallel dual-path startup.

[0032] This invention employs a parallel dual-path architecture, simultaneously activating both the optimistic and pessimistic paths in each round. The optimistic path addresses scenarios where the network is in good condition or without faults, determining an optimistic leader through polling and attempting to quickly commit that leader's block. The pessimistic path addresses scenarios where the network is complex, the optimistic leader is faulty, or the optimistic path fails to commit in a timely manner, ensuring protocol liveness through random election of a pessimistic leader combined with ABA final adjudication.

[0033] Unlike traditional serial dual-path schemes, this invention does not wait for the optimistic path to fail before starting the pessimistic path. Instead, it pre-schedules a delayed election thread for the pessimistic path within the same round. Both paths share the same DAG structure and the same GCBC broadcast process, therefore the pessimistic leader block does not need to be rebroadcast after the pessimistic path starts. If the block has already reached State 2 via GCBC, the pessimistic path can directly use the existing Done certificate to complete the commit.

[0034] Step 3: GCBC two-stage block broadcast.

[0035] like Figure 2 As shown, this invention uses the GCBC broadcast mechanism to broadcast blocks created by all replicas. GCBC consists of two consecutive consistent broadcasts, which can divide the block state into State0, State1, and State2.

[0036] State 0 indicates that a block has just been created or has not yet completed its first broadcast verification. When a replica receives a block B, it first verifies its creator's signature, round number, parent block reference, and transaction validity. After successful verification, the replica stores the block and broadcasts a Vote message to the entire network.

[0037] State 1 indicates that the block has completed its first consistent broadcast. When a replica has collected at least [number missing] consistent broadcasts for the same block... After each Vote message, the valid signature shares are aggregated, the block state is marked as State1, and the block is delivered locally. The replica then calculates the block hash digest, generates a threshold signature share from the digest, and broadcasts a Ready message.

[0038] State2 indicates that the block has completed its second consistent broadcast and obtained the Done certificate. When a replica collects at least 2f+1 Ready messages for the same block, it aggregates the threshold signature shares from the Ready messages to form the Done certificate and marks the block state as State2. Once the Done certificate is verified by any honest replica, it can eventually be obtained by other honest replicas based on the consistency and reliability of the GCBC broadcast.

[0039] Step 4: Optimistic path submission.

[0040] In each round r, the system determines the optimistic leader through a polling method. For example, As the optimistic leader of the current round, the replica starts a timer Δ upon entering this round and monitors the GCBC status of the optimistic leader block.

[0041] If the optimistic leader block reaches State 2 before the timer expires, it means the block has obtained the Done certificate, and the replicas can directly commit the optimistic leader block and its ancestor blocks, advancing to the next round. If the optimistic leader block is in State 1 when the timer expires, it means different replicas may have different verification progress for the block. The replicas broadcast HelpMsg messages to report their locally observed state and enter the final adjudication process. If the optimistic leader block is still in State 0 when the timer expires, it means the leader may be a Byzantine replica, have experienced a crash, or have severe network latency. In this case, the replicas also broadcast HelpMsg messages and tend to switch to the pessimistic path by outputting 0 in the ABA.

[0042] Step 5: Pessimistic Path - Delay Election.

[0043] The pessimistic path is used to ensure protocol liveness when the optimistic path cannot be committed in time. This invention introduces a delayed election mechanism to reduce communication overhead in normal scenarios. Specifically, after a replica enters round r, it starts a scheduleElect(r) delayed thread and waits for Δ / 2 time. After waiting, the replica first checks whether the current round has progressed. If the current round is greater than r, it means that the optimistic path has been committed and progressed, and the replica directly cancels the broadcast of the Elect message for this round. If the current round is still equal to r, it means that the optimistic path has not been committed in time, and the replica generates a threshold signature share for the election data and broadcasts the Elect message.

[0044] Once the replica has collected at least 2f+1 Elect messages, it aggregates the threshold signature shares into a complete threshold signature qc, and then calculates... The corresponding copy is then identified as the pessimistic leader for this round. Because threshold signatures are unpredictable before the collection of the threshold signature share, adversaries have difficulty knowing the identity of the pessimistic leader in advance and launching targeted attacks.

[0045] Step 6: HelpMsg mechanism and ABA final decision.

[0046] When an optimistic path fails to commit quickly, the replica constructs a HelpMsg message based on the state of the optimistic leader block in its local DAG and broadcasts it. The HelpMsg message contains at least the current round (cur_round) and the optimistic leader block state (op_leader_state). After collecting at least 2f+1 HelpMsg messages, the replica categorizes the messages according to State0, State1, and State2, and makes a decision based on the following rules.

[0047] First, if the HelpMsg set contains a State2 state, it means that at least one honest replica has observed the Done certificate. Based on GCBC reliability, this Done certificate will eventually be obtained by all honest replicas, therefore the optimistic leader block can be committed. Second, if at least 2f+1 HelpMsg messages report a State1 state, it means that the optimistic leader block has been observed by a majority of replicas to have completed a broadcast, and the decision process favoring the commit of the optimistic leader block can begin. Third, if a State1 state exists but not all State1 conditions are met, the ABA protocol with an input value of 1 is initiated. Fourth, if a State1 state does not exist and a State0 state exists, the ABA protocol with an input value of 0 is initiated.

[0048] When the ABA protocol output is 1, the replica commits the optimistic leader block; when the ABA protocol output is 0, the replica sets the optimistic path failure flag opFailed[r] to true and attempts to commit the pessimistic leader block. The pessimistic leader block is only allowed to be committed when the optimistic path failure flag is true, thus ensuring that the optimistic path and the pessimistic path will not commit two different leader blocks in the same round.

[0049] Step 7: Block submission and execution.

[0050] The replicas trace back through the ancestor blocks in the Directed Acyclic Graph (DAG) based on the finally committed leader block, forming a leader block sequence. They then determine the set of transaction blocks to be committed based on the leader block sequence and the parent reference relationships in the DAG. Subsequently, the replicas sort the transaction blocks according to deterministic rules, execute the transactions within each block, and write the execution results to persistent storage. After committing, the replicas advance to the next round and repeat the above process.

[0051] In terms of security, the optimistic leader in the same round is uniquely determined by the polling rule, while the pessimistic leader is uniquely determined by the threshold signature aggregation result. Furthermore, the pessimistic leader block is only allowed to be committed when the ABA output is 0. Since the ABA protocol is consistent, optimistic and pessimistic leader blocks will not be committed simultaneously in the same round. In different rounds, because a new block references at least 2f+1 blocks from the previous round, committed leader blocks will be directly or indirectly referenced by subsequent rounds, making the leader block sequences committed by any two honest replicas prefixes of each other, thus ensuring the consistency of the commit sequence.

[0052] Regarding liveness, if the network is in good condition, the optimistic path can complete the State2 block commit before the timer expires; if the optimistic path cannot proceed due to leader failure or network fluctuations, the pessimistic path determines a pessimistic leader through delayed election, and the ABA final ruling ensures that the protocol can still terminate in the asynchronous network. Even if the pessimistic leader in a certain round is a Byzantine copy, the protocol can still proceed to the next round of re-election, and finally complete a valid commit within the expected finite number of rounds.

[0053] At the implementation level, this invention can be implemented using the Golang language, using a message encoding and decoding library for inter-replica communication encoding, and using a threshold signature library to implement the signature aggregation of Elect messages and Done certificates. Replicas transmit blocks, Vote messages, Ready messages, Done certificates, HelpMsg messages, Elect messages and ABA protocol messages through peer-to-peer network connections.

[0054] Depend on Figure 7As can be seen, under low-load scenarios, the method proposed in this invention can maintain stable throughput and low latency in both 7-replica and 16-replica configurations. Compared to traditional DAG-based asynchronous protocols, although this invention requires all replica blocks to perform GCBC broadcasting, it still exhibits good response performance under small-batch transaction conditions through an optimistic path fast commit mechanism.

[0055] Depend on Figure 8 As can be seen, under high-load scenarios, the method proposed in this invention can achieve a good balance between throughput and latency. When the batch size increases, traditional serial backoff protocols are prone to increased latency due to path switching and broadcast waiting. However, this invention reduces path switching overhead by using parallel dual paths and sharing DAG broadcast results, thus achieving lower acknowledgment latency under high-load conditions.

[0056] Depend on Figure 9 As can be seen, in scenarios where network latency gradually increases due to simulated DDoS attacks, the method proposed in this invention still maintains good latency performance. This is because pessimistic and optimistic paths are prepared in parallel, avoiding the long wait before the fallback path is activated after the optimistic path fails; at the same time, the delayed election mechanism suppresses redundant communication in normal scenarios, while promptly activating the pessimistic path to ensure activity when the network deteriorates.

[0057] In summary, this invention, through the organic combination of parallel dual-path architecture, shared DAG ledger structure, GCBC two-phase broadcast, delayed election mechanism, HelpMsg state aggregation mechanism, and ABA final decision mechanism, significantly reduces consensus latency in complex network environments while ensuring the security and activity of the asynchronous BFT protocol, and improves the robustness and scalability of the system in high-load, faulty replica, and network adversarial scenarios.

[0058] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope disclosed in the present invention, based on the technical solution and concept of the present invention, shall fall within the scope of protection of the present invention.

Claims

1. A DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture, characterized in that, Includes the following steps: Step 1: System Initialization and DAG Ledger Construction; In an asynchronous distributed system containing n replicas, each replica has a unique identity, public key, and private key. The system establishes a Public Key Infrastructure (PKI) and adopts a collision-resistant hash function and threshold signature scheme. Each replica jointly forms a committee and maintains a DAG-style block ledger DAG_i[r] locally, where r is the consensus round. Each block contains a block digest, round, parent block set, creator, transaction set, block state, and signature. Step 2: Parallel dual-path startup; In each consensus round, both optimistic and pessimistic paths are initiated simultaneously. The optimistic path is used to quickly complete the leader block submission when the network is in good condition, while the pessimistic path is used to ensure protocol liveness when the optimistic path cannot submit in time. The two paths share the same DAG ledger structure and the same set of block broadcast results. Step 3: GCBC two-stage block broadcast; Each replica creates the current round block and references no less than 2f+1 blocks from the previous round as parent blocks. The block is broadcast twice consecutively through the GCBC broadcast mechanism: After collecting no less than 2f+1 Vote messages in the first broadcast, the block state is updated from State0 to State1 and delivered to the local DAG. The second broadcast signs the State1 block and propagates the Ready message. After collecting no less than 2f+1 Ready messages, it aggregates them to form the Done certificate and updates the block state to State2. Step 4: Optimistic Path Commit; In each round, an optimistic leader is determined through polling rules, and replicas start timers and wait for the optimistic leader block to reach State 2. If the optimistic leader block has reached State2 before or when the timer expires, the optimistic leader block and its ancestor blocks are directly committed and the process proceeds to the next round; if the optimistic leader block has not reached State2, the final adjudication process begins. Step 5: Pessimistic Path Delayed Election; After each round begins, the replica starts a delayed election thread and waits for a preset delay time; If the optimistic path has progressed to a subsequent round during the waiting period, the pessimistic path election message broadcast is skipped; if the current round has not progressed after the waiting period, each replica broadcasts an Elect message carrying the threshold signature share. When at least 2f+1 Elect messages are collected, the threshold signatures are aggregated and the pessimistic leader is determined by hash mapping. Step 6: HelpMsg Mechanism and ABA Final Decision; When the optimistic path is not committed quickly, each replica constructs and broadcasts a HelpMsg message based on the state of the optimistic leader block in its local DAG. The HelpMsg message includes at least the optimistic leader block state and the current round. After collecting no less than 2f+1 HelpMsg messages, it is determined whether to commit directly or start the ABA protocol based on the distribution of State0, State1, and State2 in the HelpMsg message. When the ABA protocol output is 1, the optimistic leader block is committed; when the ABA protocol output is 0, the optimistic path failure flag is set and the pessimistic leader block is committed. Step 7: Block sequence submission and round-by-round advancement; The replica traces back the ancestor blocks in the DAG based on the submitted leader block, generates a sequence of submitted leader blocks and transaction blocks, executes the transactions in the blocks and persists the execution results, and then advances to the next consensus round.

2. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, The asynchronous distributed system described in step 1 satisfies n≥3f+1, where f is the maximum number of Byzantine replicas that the system can tolerate; messages between honest replicas can eventually arrive; Byzantine replicas can arbitrarily delay, tamper with, discard, or forge their own messages, but cannot forge the digital signature, threshold signature share, or hash digest of honest replicas.

3. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, Step 3 of the GCBC two-phase block broadcast includes: after receiving and verifying the block, the replica broadcasts a Vote message; when the block receives no less than 2f+1 Vote messages, it aggregates the signature shares in the Vote messages and marks the block state as State1; the replica performs threshold signing on the hash digest of the State1 block and broadcasts a Ready message; when it receives no less than 2f+1 Ready messages, it aggregates to form a Done certificate and marks the block state as State2; all replica blocks perform a full GCBC broadcast so that the pessimistic leader block has the possibility of completing the broadcast before the pessimistic leader is determined.

4. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, The optimistic path submission described in step 4 specifically includes: the optimistic leader is determined by polling node[r mod n]; if a replica observes locally that the optimistic leader block has reached State 2, or confirms through a HelpMsg message that at least one honest replica has observed the Done certificate of the block, then the optimistic leader block and its ancestor blocks determined by the DAG parent reference relationship are submitted; if the optimistic leader block has only reached State 1 or is still in State 0, it is not submitted immediately, but enters the HelpMsg mechanism and the ABA final decision process.

5. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, The delayed election mechanism described in step 5 is as follows: after entering the r-th round, the replica waits for Δ / 2 time, where Δ is the optimistic path timer threshold; if the current round is greater than r before the waiting ends, it is determined that the optimistic path has been completed and the Elect message broadcast is canceled; if the current round has not been completed, the replica generates a threshold signature share for the election data and broadcasts the Elect message. After collecting no less than 2f+1 Elect messages, the signature shares are aggregated into a threshold signature qc, and the pessimistic leader is determined by leaderId=H(qc) modn, thereby ensuring the unpredictability and consistency of the pessimistic leader election.

6. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, The HelpMsg mechanism described in step 6 includes the following decision rules: if the collected HelpMsg messages contain a State2 state, then the optimistic leader block is determined to be committable; If all 2f+1 HelpMsg messages report State1, the optimistic leader block can enter the commit process or participate in the ABA protocol with input value 1. If State1 exists but not all State1 conditions are met, the ABA protocol with input value 1 is started. If State1 does not exist and State0 exists, the ABA protocol with input value 0 is started. The optimistic leader block is committed when the ABA protocol output is 1, and the pessimistic leader block is committed when the output is 0.

7. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, In step 6, optimistic and pessimistic paths are mutually exclusive in their submissions: in the same round, the pessimistic leader block is only allowed to be submitted when the ABA protocol output is 0 and the optimistic path failure flag is true; When the ABA protocol output is 1 or the optimistic leader block has met the commit conditions, the pessimistic leader block must not be committed as the final leader block in that round, thus preventing two paths from committing different leader blocks in the same round.

8. The DAG-based asynchronous Byzantine fault-tolerant consensus method based on a parallel dual-path architecture as described in claim 1, characterized in that, The block sequence submission in step 7 is as follows: For any submitted leader block, the replica traces back its ancestor leader block along the DAG parent reference relationship to form a leader block sequence; then, the set of transaction blocks to be submitted is determined according to the ancestor path and round order corresponding to the leader block sequence, and the transactions are executed in a deterministic order and written to persistent storage, so that the block sequences submitted by any two honest replicas are prefixes of each other.

Images