Fast asynchronous consensus implementation method based on directed acyclic graph

Abstract

A kind of fast asynchronous consensus implementation method based on directed acyclic graph, when node proposes vote, directed acyclic graph (DAG) is built, and fast confirmation or coin confirmation is carried out after the vertex quantity of any layer satisfies condition, finally, it is submitted to execute in layer unit.This application uses directed acyclic graph (DAG) as the topological structure of block, and applies the method for fast completing consensus of semi-synchronous protocol to asynchronous protocol, to realize the asynchronous consensus with fast consensus path based on DAG.

Description

Technical Field

[0001] This invention relates to a technology in the field of distributed information processing, specifically a fast asynchronous consensus implementation method based on directed acyclic graphs. Background Technology

[0002] Distributed systems rely on consensus algorithms to ensure the consistency of information among nodes. While asynchronous consensus does not have strict time assumptions, it cannot guarantee the timeliness and orderliness of messages. Existing asynchronous consensus mechanisms proceed in a non-deterministic manner, allowing the entire algorithm to terminate over an arbitrarily long time, thus increasing system latency.

[0003] Asynchronous consensus based on Directed Acyclic Graphs (DAGs) allows each node to store received blocks locally and sort them independently from its own perspective. However, existing implementations still suffer from excessively long chain-fixing times. Summary of the Invention

[0004] This invention addresses the drawback of the excessively time-consuming sorting and chaining of DAGs in existing technologies by proposing a fast asynchronous consensus implementation method based on Directed Acyclic Graphs (DAGs). By using DAGs as the topology of blocks, the invention applies the semi-synchronous protocol's method of quickly completing consensus to the asynchronous protocol, thereby achieving asynchronous consensus based on DAGs with a fast consensus path.

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

[0006] This invention relates to a fast asynchronous consensus implementation method based on a directed acyclic graph (DAG). After a node proposes a vote, a DAG is constructed, and fast confirmation or coin confirmation is performed when the number of vertices in any layer meets the condition. Finally, the submission is performed on a layer-by-layer basis.

[0007] The aforementioned rapid confirmation refers to: counting the number of links of any layer of vertices; when the number of vertices in that layer meets the condition, a rapid confirmation phase is carried out, in which each vertex is either in an active state or a passive state.

[0008] The condition regarding the number of vertices is that all 3f+1 vertices in any layer are either in an active state or a passive state, where:

[0009] An active state means that there are at least 2f+1 vertices in the next layer that are connected to this vertex;

[0010] A negative state is defined as: there are at least 2f+1 vertices in the next layer that are not connected to this vertex.

[0011] The aforementioned coin confirmation refers to: any layer randomly determines a leader by a random number, and the leader confirms the state of the vertices two layers prior. That is, for the vertices two layers prior, if there are at least f+1 different paths leading to the leader, it is a positive state; otherwise, it is a negative state.

[0012] This invention relates to a system for implementing the above method, comprising: a client transaction processing module, a local DAG construction module, a fast confirmation module, a coin confirmation module, and a transaction submission execution module, wherein: the client transaction processing module generates blocks based on client requests and broadcasts them to other distributed system nodes; the local DAG construction module receives messages from other nodes and constructs a local DAG view based on the message content; the fast confirmation module determines whether each layer in the DAG meets the fast confirmation conditions, and if so, performs fast confirmation to determine whether the node in that layer is in an active or passive state; otherwise, the node state of that layer is determined by the coin confirmation module; the coin confirmation module is used to confirm DAG layers that do not meet the fast confirmation conditions and determines their node state according to the coin confirmation rules; the transaction submission execution module executes the request for the block corresponding to the active node.

[0013] Technical effect

[0014] The fast confirmation path of this invention significantly reduces latency in distributed consensus systems, allowing client requests to be executed after only three rounds of peer-to-peer communication. The coin confirmation path ensures that layers that do not meet the fast confirmation criteria can ultimately be executed, increasing the overall system throughput. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the system of the present invention;

[0016] Figure 2 A schematic diagram of the DAG constructed for the example;

[0017] Figure 3 This is a schematic diagram for quick confirmation of the embodiment;

[0018] Figure 4 This is a schematic diagram illustrating coin confirmation as an example.

[0019] Figures 5-7 This is a schematic diagram illustrating the effect of an example. Detailed Implementation

[0020] This embodiment relates to a method for implementing fast asynchronous consensus based on a directed acyclic graph in a distributed system of an application. Based on n consensus nodes, where the number of Byzantine nodes that can perform any attack behavior but cannot break cryptographic primitives is f, and it is required that f < n / 3. Each node sends a consensus block in units of rounds. Each correct node sends at most and must send one block in one round.

[0021] As Figure 1 shown, this embodiment specifically includes the following steps:

[0022] Step 1, Proposal Voting: Each node sends a pre-prepare message to all nodes at the beginning of each round. After other nodes receive it, they check the information in it. When it meets the voting requirements, they broadcast a prepare message to indicate support for voting on this block. When a node receives 2f + 1 prepare messages for the same block, it sends a ready message to indicate that it already knows that most nodes recognize this block. When a node receives 2f + 1 ready messages for the same block, this block completes the proposal voting stage.

[0023] The pre-prepare message includes: information about the block to be proposed by this node in this round.

[0024] The proposed voting determines the uniqueness of each round of blocks by allowing nodes to complete the broadcast and voting of blocks. As an asynchronous consensus implementation, this method needs to send two types of voting information (prepare and ready) at this stage, which can give nodes more time to construct the local DAG view before entering the next round and receive as complete block information of this round as possible. This design is closely related to the subsequent DAG construction and fast confirmation stages.

[0025] Step 2, Local DAG Construction of Each Node: Each node constructs a DAG as Figure 2 shown in the following manner through the messages received in each round, specifically:

[0026] a. Each block corresponds to a vertex in the DAG. Each round of the consensus process corresponds to a layer of the DAG, and there are at most 3f + 1 vertices in each layer of the DAG;

[0027] b. A block is added to the node's DAG after receiving 2f + 1 prepare support votes;

[0028] c. The vertices in the r-th layer are linked to at least 2f + 1 and at most 3f + 1 vertices in the r - 1-th layer. These vertices are the vertices corresponding to the blocks that received at least 2f + 1 prepare support votes in the r - 1-th layer when the block in the r-th layer was proposed.

[0029] When any node finds that there are 2f+1 vertices in one layer of the local DAG, it can proceed to the next round, that is, return to step 1, and simultaneously proceed to step 3 to determine whether the previous layer of the DAG meets the fast confirmation condition.

[0030] Step 3: Perform quick confirmation on a layer-by-layer basis: When there are 2f+1 vertices in the (r+1)th layer, determine whether the rth layer meets the quick confirmation condition. If it does, perform quick confirmation and then proceed to step 5; otherwise, proceed to step 4.

[0031] The aforementioned fast confirmation involves counting the number of links to vertices in layer r. When the r-th layer meets the fast confirmation condition and passes through the fast confirmation phase, each vertex is either in an active state or a passive state.

[0032] The condition for the r-th layer to be quickly identified is that all 3f+1 vertices in the r-th layer satisfy one of the following two conditions:

[0033] a. There are at least 2f+1 vertices connected to it in the (r+1)th layer, which is an active state;

[0034] b. In the (r+1)th layer, there are at least 2f+1 vertices that are not connected to it, i.e., they are in a negative state.

[0035] like Figure 3 As shown, to indicate the timing of rapid confirmation, after rapid confirmation at the r-th layer, vertices A, B, and C are in an active state, while vertex D is in a passive state.

[0036] Step 4, Coin confirmation based on random source: Each layer will randomly determine a leader vertex through random numbers. The leader vertex will confirm the state of the vertices two layers prior to it. That is, the leader vertex of the (r+2)th layer determines the state of the vertices of the rth layer.

[0037] To prevent the possibility of a randomly selected, non-existent, or incorrectly linked primary vertex, its validity must be checked after it is determined. Only if the primary vertex is valid will it be used for coin confirmation. The condition for a valid primary vertex in layer r is that there are at least f+1 vertices in layer r+1 that link to it. If the primary vertex in layer r is invalid, the coin confirmation phase is paused until the primary vertex in layer r+2k (k>0) is valid, at which point confirmation is returned recursively.

[0038] The state confirmation refers to the following: for each vertex in layer r, if there are at least f+1 different paths leading to a valid master vertex in layer r+2k (k>0), it is in an active state; otherwise, it is in a passive state. The following diagram illustrates the coin confirmation process in layer r. The gray vertex in layer r+2 is a randomly generated master vertex, which is linked by more than f+1 vertices in layer r+3, and therefore is a valid master vertex, capable of coin confirmation in layer r. Vertices A, B, and C in layer r all have at least f+1 different paths leading to the master vertex, and are in an active state, while vertex D is in a passive state.

[0039] Step 5: Commit and execute on a layer-by-layer basis: For the r-th layer to be committed, both of the following conditions must be met simultaneously:

[0040] a. The r-th layer completes the confirmation phase (regardless of whether it is quick confirmation or coin confirmation);

[0041] b. The (r-1)th layer completes the submission and execution phase (excluding the 1st layer).

[0042] Once a layer is committed, the blocks corresponding to the vertices in an active state within that layer can be executed. Furthermore, tracing back through the DAG, all vertices linked to active vertices in that layer that have not yet been executed are also executed at this time. Condition b guarantees that all blocks are executed sequentially, layer by layer.

[0043] Through specific practical experiments, the above system was deployed on a rented server on the AWS platform. The system's throughput and latency were tested, and it was compared with the existing Tusk algorithm (Danezis G, Kokoris-Kogias L, Sonnino A, et al. Narwhal and Tusk: a DAG-based mempool and efficient BFT consensus[C] / / Proceedings of the Seventeenth European Conference on Computer Systems.2022:34-50.) and BullShark algorithm (Giridharan N, Kokoris-Kogias L, Sonnino A, et al. Bullshark: DAG bft protocols made practical[J]. arXiv preprint arXiv:2201.05677,2022.).

[0044] The system's performance was tested in experiments with different node counts (n=4, 10, and 100). All nodes were distributed across five regions: Ohio, Singapore, Tokyo, Central Canada, and Frankfurt, with an average ping latency of approximately 135ms between them.

[0045] Test results are as follows Figures 5-7 The graph shows the throughput and latency curves for system nodes n=4, 10, and 100, respectively. The vertical axis represents latency, and the horizontal axis represents throughput. Each curve indicates that as the system's request pressure increases, the throughput continuously increases until it reaches the system's limit, at which point the throughput stops increasing, while latency increases. The flat portion of the first half of the curve represents the system's latency under light load. The vertically upward inflection point of the curve represents the system's maximum throughput.

[0046] Comparison of this invention with the Tusk algorithm:

[0047] Tusk, also a consensus protocol based on DAG design, lacks a fast confirmation mechanism; all vertex confirmations rely on a randomly confirmed master vertex. The overall expected latency of this method is three times that of our approach. Tusk generates a random master vertex every two layers. When a node fails, the probability of an invalid master vertex increases, further increasing the overall latency. Our approach provides a fast confirmation path unaffected by failed nodes. Therefore, when system failures exist, Tusk's expected latency is five times that of our approach. Our approach demonstrates significantly better robustness than Tusk.

[0048] When the fast confirmation condition of this method is not met, all vertices of all layers are confirmed through the coin confirmation phase, and the overall system delay will be 1 / 2 rounds longer than that of Tusk.

[0049] Comparison of this invention with the BullShark algorithm:

[0050] BullShark's fast consensus path is based on a semi-synchronous time assumption, requiring pre-setting timeout parameters and a list of synchronizing master vertices. In cases of significant network fluctuations or faulty nodes, it relies on triggering a timeout mechanism to drive the protocol forward. This method is a purely asynchronous algorithm, offering greater adaptability and robustness in wide area network environments compared to BullShark. When there is a unequal latency between nodes, BullShark needs to wait for votes from slower nodes, increasing the overall consensus latency. In contrast, this method's round-robin progression only relies on the fastest 2f+1 nodes, preventing the system from being dragged down by the slowest nodes. Even with significant latency differences between nodes, this method offers lower latency than BullShark.

[0051] This method cannot guarantee that all blocks proposed by nodes will be executed. In contrast, in the BullShark algorithm's DAG, each vertex can connect to unconnected vertices in lower rounds, ultimately ensuring that valid blocks will be executed. BullShark has an advantage in terms of node fairness.

[0052] Compared to existing technologies, the fast confirmation phase in this method allows most blocks to be determined after 5 communication rounds, skipping the random process and significantly reducing consensus system latency. This method uses a purely asynchronous time assumption, eliminating the need for preset timeout parameters, making the system more adaptable to wide-area network applications with high latency. This method utilizes a Directed Acyclic Graph (DAG) as the block topology, enabling more coordinated consensus node behavior and ensuring stable performance even in large-scale node systems. The method's assessment of node negative states allows the system to quickly detect faulty nodes, ensuring strong system robustness; even with up to f node failures, the protocol can still proceed in a fast confirmation mode. This method combines voting and message ordering from some traditional consensus protocols with the linking of preceding and following vertices in a DAG, allowing nodes to obtain consensus information through their local DAG view, reducing the system's information interaction load.

[0053] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A fast asynchronous consensus implementation method based on directed acyclic graphs, characterized in that, After a node proposes a vote, a directed acyclic graph is constructed. Once the number of vertices at any level meets the condition, fast confirmation or coin confirmation is performed. Finally, the graph is committed and executed layer by layer. The aforementioned rapid confirmation refers to: counting the number of links of any layer of vertices; when the number of vertices in that layer meets the condition, a rapid confirmation phase is carried out, in which each vertex is either in an active state or a passive state. The aforementioned coin confirmation refers to: any layer randomly determines a leader vertex using a random number, and this leader vertex confirms the state of the vertices two layers prior. That is, for vertices two layers prior, if there are at least f+1 different paths leading to the leader vertex, then it is a positive state. Otherwise, it is a negative state, specifically including: Step 1, Proposal Voting: At the beginning of each round, each node sends a pre-prepare message to all nodes. Other nodes receive the message and verify the information. If the message meets the voting requirements, the node broadcasts a prepare message to indicate its support for the block. When a node receives 2f+1 prepare messages for the same block, it sends a ready message to indicate that it knows most nodes approve of the block. Once a node receives 2f+1 ready messages for the same block, the proposal voting phase for that block is complete. Step 2, Local DAG Construction for Each Node: Each node constructs a DAG based on the messages received in each round, specifically as follows: a. Each block corresponds to a vertex in the DAG, and each round of the consensus process corresponds to one layer of the DAG. Each layer of the DAG has a maximum of 3f+1 vertices. b. A block is added to the node's DAG after receiving 2f+1 prepare support tickets; c. The vertices of the r-th layer are linked to at least 2f+1 and at most 3f+1 vertices of the r-1 layer. These vertices are the vertices corresponding to the blocks that have collected at least 2f+1 prepare support tickets in the r-1 layer when the r-th layer block is proposed. When any node finds that there are 2f+1 vertices in one layer of the local DAG, it can enter the next round, that is, return to step 1, and simultaneously enter the judgment of step 3 in parallel to determine whether the previous layer of the DAG meets the fast confirmation condition. Step 3: Perform quick confirmation on a layer-by-layer basis: If there are 2f+1 vertices in the (r+1)th layer, determine whether the rth layer meets the quick confirmation condition. If it does, perform quick confirmation and then proceed to step 5; otherwise, proceed to step 4. The aforementioned fast confirmation refers to counting the number of links of vertices in layer r. When the r-th layer meets the fast confirmation condition and passes through the fast confirmation stage, each vertex is either in an active state or a passive state. The condition for the r-th layer to be quickly identified is that all 3f+1 vertices in the r-th layer satisfy one of the following two conditions: a. There are at least 2f+1 vertices connected to it in the (r+1)th layer, which is an active state; b. In the (r+1)th layer, there are at least 2f+1 vertices that are not connected to it, i.e., they are in a negative state. Step 4, Coin confirmation based on random source: Each layer will randomly determine a master vertex through random number, and the master vertex will confirm the state of the vertices two layers before it. That is, the master vertex of the (r+2)th layer determines the state of the vertices of the rth layer. The state confirmation refers to the following: for each vertex in the r-th layer, if there are at least f+1 different paths leading to the valid main vertex in the r+2k-th layer, it is an active state; otherwise, it is a passive state. The following figure shows the coin confirmation process in the r-th layer. The gray vertex in the r+2-th layer is a randomly generated main vertex, which is linked by more than f+1 vertices in the r+3-th layer, so it is a valid main vertex and can be used for coin confirmation in the r-th layer. Vertices A, B, and C in the r-th layer all have at least f+1 different paths leading to the main vertex and are in an active state, while vertex D is in a passive state, where: k>0; Step 5: Commit and execute on a layer-by-layer basis: For the r-th layer to be committed, both of the following conditions must be met simultaneously: a) The r-th layer completes the confirmation phase, regardless of whether it is quick confirmation or coin confirmation; b. Except for the first layer, the (r-1)th layer completes the submission and execution phase; Once a layer is committed, the blocks corresponding to the vertices in an active state in that layer can be executed. Furthermore, by tracing back in the DAG, all vertices that are linked to the vertices in an active state in that layer but have not yet been executed are also executed at this time. Condition b guarantees that all blocks are executed sequentially in layer order.

2. The fast asynchronous consensus implementation method based on directed acyclic graphs according to claim 1, characterized in that, The condition regarding the number of vertices is that all 3f+1 vertices in any layer are either in an active state or a passive state, where: An active state means that there are at least 2f+1 vertices in the next layer that are connected to this vertex; A negative state is defined as: there are at least 2f+1 vertices in the next layer that are not connected to this vertex.

3. The fast asynchronous consensus implementation method based on directed acyclic graphs according to claim 1, characterized in that, The proposed voting, by having nodes broadcast and vote on blocks, determines the uniqueness of each round of blocks. That is, by sending two types of voting information, prepare and ready, nodes have more time to construct their local DAG view before entering the next round and receive the block information of this round as completely as possible.

4. The fast asynchronous consensus implementation method based on directed acyclic graphs according to claim 1, characterized in that, To prevent the random primary vertex from being missing or incorrectly linked, its validity must be checked after it is determined. Only when the primary vertex is valid will it be used for coin confirmation. The condition for the validity of the primary vertex in the r-th layer is that there are at least f+1 vertices in the (r+1)-th layer that link it. If the primary vertex in the r-th layer is invalid, the coin confirmation phase is suspended until the primary vertex in the (r+2k)-th layer is valid, and then the confirmation is returned recursively.

5. A system for implementing the fast asynchronous consensus implementation method based on directed acyclic graphs as described in any one of claims 1-4, characterized in that, include: The system comprises a client-side transaction processing module, a local DAG construction module, a fast confirmation module, a coin confirmation module, and a transaction submission execution module. Specifically: the client-side transaction processing module generates blocks based on client requests and broadcasts them to other distributed system nodes; the local DAG construction module receives messages from other nodes and constructs a local DAG view based on the message content; the fast confirmation module determines whether each layer in the DAG meets the fast confirmation conditions, and if so, performs fast confirmation to determine whether the node in that layer is in an active or passive state; otherwise, the node state is determined by the coin confirmation module; the coin confirmation module confirms DAG layers that do not meet the fast confirmation conditions and determines their node state according to the coin confirmation rules; and the transaction submission execution module executes the request for the block corresponding to the active node.

Images