Asynchronous Byzantine consensus fault-tolerant method based on consistent broadcast and fast path

Abstract

The invention belongs to the technical field of block chains, and particularly discloses an asynchronous Byzantine consensus fault tolerance method based on consistent broadcast and a fast path. According to the application, the transaction is packaged, and a delivery block is determined in a mode of broadcasting the packaged block to other consensus nodes by adopting a linear consistency broadcast protocol; the local timeout device is used for starting other consensus nodes; if the fast message from the target consensus node is received before timeout, verifying the correctness of the fast message; and when the verification is passed, marking the delivery block according to the submittable label, and submitting the marked delivery block through the fast path. Through the above mode, the linear consistency broadcast protocol is adopted to replace a conventional reliable broadcast protocol, the communication complexity of block broadcast is reduced, the fast path is set, the fast path is preferentially performed under the condition that the network is good or no Byzantine behavior exists, and the number of communication rounds is reduced, so that the communication overhead and delay of consensus can be effectively reduced.

Description

Asynchronous Byzantine consensus fault-tolerant method based on consistent broadcast and fast path Technical Field

[0001] This application belongs to the field of blockchain technology, and more specifically, relates to an asynchronous Byzantine consensus fault-tolerant method based on consistent broadcasting and fast path. Background Technology

[0002] Asynchronous Byzantine Fault Tolerance (BFT) protocols play a crucial role in ensuring system consistency in distributed systems, particularly in decentralized scenarios like blockchains. However, existing asynchronous BFT protocols (such as the HoneyBadgerBFT protocol based on the BKR paradigm) generally suffer from performance bottlenecks such as excessive communication overhead and high consensus latency. For instance, using traditional Reliable Broadcast (RBC) protocols in asynchronous BFT protocols introduces significant communication complexity, making it difficult to maintain stable performance with a large number of nodes, resulting in high communication overhead. Furthermore, the asynchronous binary agreement (ABA) protocol upon which asynchronous BFT protocols rely requires multiple iterations, further increasing latency. Therefore, the communication overhead and latency of these consensus methods are high. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this application aims to provide an asynchronous Byzantine consensus fault-tolerant method based on consistent broadcasting and fast paths. This method addresses the problem of high communication overhead and latency in consensus-building caused by the need for multiple iterations in traditional reliable broadcasting protocols and asynchronous binary consensus protocols.

[0004] To achieve the above objectives, in a first aspect, this application provides an asynchronous Byzantine consensus fault-tolerant method based on consistent broadcasting and fast paths, comprising:

[0005] When a transaction submitted by a client is detected, the transaction is packaged by the target consensus node, and the packaged block is broadcast to other consensus nodes using a linear consistency broadcast protocol to determine the delivery block. When a pre-fast message is detected from other consensus nodes to the target consensus node, the local timeout of the other consensus nodes is started. If a fast message is received from the target consensus node before the timeout, the correctness of the fast message is verified. If the verification passes, the delivery block is marked according to the committable tag, and the marked delivery block is submitted through the fast path.

[0006] In one embodiment, the step of determining the delivery block by packaging the transaction through a target consensus node and broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol when a transaction submitted by a client is detected includes: storing the transaction in a waiting-to-be-packaged queue when a transaction submitted by a client is detected; selecting a batch of transaction data containing the transaction from the waiting-to-be-packaged queue through the target consensus node and packaging the batch of transaction data; broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol, and having the other consensus nodes calculate the hash value of the packaged block, generate a partial threshold signature based on the hash value, and feed the partial threshold signature back to the target consensus node; generating a complete threshold signature based on each of the partial threshold signatures, broadcasting the complete threshold signature to the other consensus nodes using the linear consistency broadcast protocol, and determining the delivery block based on the verification results of the other consensus nodes.

[0007] In one embodiment, before the step of verifying the correctness of the fast message if it is detected that other consensus nodes have received a fast message from the target consensus node before the timeout, the method further includes: counting the current number of pre-fast messages received by the target consensus node; obtaining the total number of consensus nodes and the number of Byzantine nodes, and calculating a quantity threshold based on the total number and the number of Byzantine nodes; when the current number is greater than or equal to the quantity threshold, aggregating the current number of pre-fast messages to obtain a fast message; and broadcasting the fast message to other consensus nodes through the target consensus node.

[0008] In one embodiment, after the step of activating the local timeout of the other consensus nodes when a pre-fast message is detected being fed back to the target consensus node, the method further includes: if it is detected that the other consensus nodes have not received a fast message from the target consensus node before the timeout and / or there are still blocks not delivered through the linear consistency broadcast protocol after the delivery blocks have been marked with a quantity threshold, then the method falls back to the normal path corresponding to the asynchronous binary consensus protocol; obtains the block reception results of the other consensus nodes, and generates a preparation message for the other consensus nodes based on the block reception results during the preparation phase; when a preparation message with a quantity threshold is received, counts the number of broadcast binary values ​​of the preparation message that are equal to a first value; and when the number of broadcast binary values ​​that are equal to the quantity threshold is equal to the quantity threshold, directly submits the delivery block.

[0009] In one embodiment, after the step of counting the number of preparation messages with a broadcast value of a first value when a preparation message with a quantity threshold is received, the method further includes: when the number of preparation messages with a broadcast value of the first value is less than the quantity threshold, obtaining the number of preparation messages with a broadcast value of a second value; when the number of preparation messages with a broadcast value of the second value is less than the quantity threshold, participating in multiple rounds of voting in the asynchronous binary consensus protocol with preparation messages with a broadcast value of the first value as the first input; when the first output after multiple rounds of voting is the same as the first input, submitting the delivery block through the normal path; when the number of preparation messages with a broadcast value of the second value is equal to the quantity threshold, using preparation messages with a broadcast value of the second value as the second input, and when the second output after multiple rounds of voting is the same as the second input, abandoning the submission of the delivery block.

[0010] In one embodiment, after determining the delivery block by packaging the transaction through the target consensus node and broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol when a transaction submitted by the client is detected, the method further includes: triggering a block retrieval mechanism when any consensus node has a complete threshold signature but lacks local block content; controlling the any consensus node to send block content request information to other consensus nodes based on the triggered block retrieval mechanism; parsing the feedback information upon receiving feedback information from other consensus nodes and verifying the parsed complete threshold signature; and supplementing the any consensus node with the parsed block content upon successful verification, and then sending a pre-fast message through the supplemented consensus node.

[0011] Secondly, this application provides an asynchronous Byzantine consensus fault-tolerant device based on consistent broadcasting and fast path, comprising: a determination module, configured to, upon detecting a transaction submitted by a client, package the transaction through a target consensus node and broadcast the packaged block to other consensus nodes using a linear consistent broadcasting protocol to determine a delivery block; a detection module, configured to, upon detecting that other consensus nodes have fed back a pre-fast message to the target consensus node, activate the local timeout of the other consensus nodes; the detection module is further configured to, if it is detected that the other consensus nodes have received a fast message from the target consensus node before the timeout, verify the correctness of the fast message; and a consensus module, configured to, upon successful verification, mark the delivery block according to a committable tag and submit the marked delivery block via the fast path.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] Overall, the above technical solutions conceived in this application have the following beneficial effects compared with the prior art: (1) After the transaction is packaged into a block by the target consensus node, this application adopts a linear consistency broadcast protocol to replace the conventional reliable broadcast protocol, broadcasts the packaged block to other consensus nodes, calculates the hash value of the packaged block and carries a partial threshold signature, broadcasts the complete threshold signature to other consensus nodes, and determines the delivery of the block when other consensus nodes receive and verify it, thereby significantly reducing the communication overhead of the broadcast stage and reducing the complexity of the broadcast stage from O(n³) to O(n²).

[0017] (2) This application will also set up a fast path, which will be prioritized when the network is good or there is no Byzantine behavior. That is, if other consensus nodes receive a fast message from the target consensus node before the timeout, the correctness of the fast message will be verified. When the verification is successful, the delivery block will be marked according to the committable tag, and the marked delivery block will be submitted through the fast path. That is, only two rounds of communication are needed to submit the block, which can effectively reduce the latency.

[0018] (3) This application also proposes a preparation phase that is essentially an additional round of message broadcasting. In this preparation phase, preparation messages for other consensus nodes are generated based on the block reception results. When a preparation message with a certain number of threshold values ​​is received, the number of broadcast binary values ​​of 1 and 0 for the preparation messages are counted respectively. When the number of broadcast binary values ​​of 1 equals the number threshold, the block is directly submitted. When there is at least one broadcast 1, the preparation message with a broadcast value of 1 is used as the first input. When the first output is the same as the first input, the delivery block is submitted through the normal path. When the number of broadcast values ​​of 0 equals the number threshold, the preparation message with a broadcast value of 0 is used as the second input. When the second output is the same as the second input, the submission of the delivery block is abandoned, so that consensus nodes can ensure the consistency of input during path switching. In addition, this application also sets up a block retrieval triggering mechanism. For consensus nodes with complete threshold signatures and missing block content locally, when supplementing any consensus node, the complete threshold signature of the parsed block will also be verified, thereby ensuring the security of the supplemented block content.

[0019] In summary, this application, upon detecting a transaction submitted by a client, packages the transaction into a block by the target consensus node and broadcasts the packaged block to other consensus nodes using a linear consistency broadcast protocol to determine the delivery block. When other consensus nodes send pre-fast messages to the target consensus node, their local timeouts are activated. If another consensus node receives a fast message from the target consensus node before the timeout, the correctness of the fast message is verified. If the verification passes, the delivery block is marked with a committable tag, and the marked delivery block is submitted via the fast path. By replacing the conventional reliable broadcast protocol with a linear consistency broadcast protocol, the communication complexity of block broadcasting is reduced. Furthermore, a fast path is prioritized when the network is good or there is no Byzantine fault tolerance, reducing the number of communication rounds and effectively lowering consensus communication overhead and latency. Attached Figure Description

[0020] Figure 1 is one of the flowcharts of the asynchronous Byzantine consensus fault-tolerant method based on consistent broadcast and fast path provided in the embodiments of this application; Figure 2 is another flowchart of the asynchronous Byzantine consensus fault-tolerant method based on consistent broadcast and fast path provided in the embodiments of this application; Figure 3 is a schematic diagram of the module structure of the asynchronous Byzantine consensus fault-tolerant device based on consistent broadcast and fast path provided in the embodiments of this application; Figure 4 is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] Based on this, this application provides an asynchronous Byzantine consensus fault-tolerance method based on consistent broadcasting and fast path. Referring to Figure 1, Figure 1 is one of the flowcharts of the asynchronous Byzantine consensus fault-tolerance method based on consistent broadcasting and fast path provided in this application. In this embodiment, the asynchronous Byzantine consensus fault-tolerance method based on consistent broadcasting and fast path includes steps S10 to S40: Step S10, when a transaction submitted by the client is detected, the transaction is packaged by the target consensus node, and the packaged block is broadcast to other consensus nodes using a linear consistent broadcasting protocol to determine the delivery block.

[0026] It should be noted that the client refers to the object that generates a transaction and initiates the submission. In this embodiment, consensus nodes are divided into target consensus nodes and other consensus nodes. The target consensus node refers to the node that proposes consensus. Therefore, the target consensus node can also be called the block proposal node. The total number of consensus nodes n satisfies n=3f+1, where f represents the number of Byzantine nodes.

[0027] It should be understood that when a transaction is detected by the client, it indicates that the client has sent the transaction to the target consensus node. At this point, the target consensus node can package the transaction into a block. The delivered block refers to the block after all other consensus nodes have received and verified the complete threshold signature; this delivered block has consistency. After the broadcast phase of the linear consistency broadcast protocol is complete, if other consensus nodes receive the block, a fast path is triggered, requiring only two rounds of communication to submit the block, significantly reducing latency.

[0028] Furthermore, after step S10, the method further includes: triggering a block retrieval mechanism when any consensus node is detected to have a complete threshold signature but lacks local block content; controlling the any consensus node to send block content request information to other consensus nodes based on the triggered block retrieval mechanism; parsing the feedback information upon receiving feedback information from other consensus nodes and verifying the parsed complete threshold signature; and supplementing the any consensus node with the parsed block content upon successful verification, and then sending a pre-fast message through the supplemented consensus node.

[0029] It is understandable that this embodiment uses the Consistency Broadcast (CBC) protocol to replace the conventional reliable broadcast protocol for broadcasting packaged blocks to other consensus nodes. However, the CBC protocol carries a risk that a consensus node may possess a complete threshold signature but lack the block content locally. Therefore, if this risk is not mitigated, blocks may fail to be committed, rendering the protocol inactive. To address this, this embodiment introduces a block retrieval mechanism that continuously monitors all consensus nodes for instances where they possess a complete threshold signature but lack the block content locally. Upon detecting such a situation in any consensus node, the block retrieval mechanism is triggered.

[0030] It should be noted that since submitting a block requires the participation of at least 2f+1 nodes, with at least f+1 being correct consensus nodes, if any consensus node lacks local block content but believes the block is committable, it can request the missing block content from other consensus nodes to maintain protocol liveness. For a consensus node with a complete threshold signature and missing local block content, it sends a block content request message to other consensus nodes, requesting feedback on the missing block content. Upon receiving the request message, other consensus nodes use the complete threshold signature determined using the linear consensus broadcast protocol as proof and generate feedback information based on their own block content. To verify the reliability of the block content and ensure the security of supplementing the block content, consensus nodes with a complete threshold signature and missing local block content also verify the parsed complete threshold signature and supplement any consensus node based on the parsed block content. At this point, the consensus node has a complete threshold signature and does not lack local block content, and has the ability to provide pre-fast feedback messages.

[0031] Step S20: When it is detected that the other consensus nodes are sending a pre-fast message to the target consensus node, the local timeout of the other consensus nodes is started.

[0032] Understandably, a PREFAST message refers to a message that carries a complete threshold signature for the delivered block. Other consensus nodes will send this PREFAST message back to the target consensus node and simultaneously start a local timeout to determine whether to fall back to the normal path corresponding to the asynchronous binary consensus protocol.

[0033] Further, after step S20, the method includes: if it is detected that other consensus nodes have not received a fast message from the target consensus node before the timeout and / or there are still blocks that have not been delivered through the linear consensus broadcast protocol after the delivery blocks have been marked with a quantity threshold, then the method falls back to the normal path corresponding to the asynchronous binary consensus protocol; obtains the block reception results of other consensus nodes, and generates preparation messages for other consensus nodes based on the block reception results during the preparation phase; when a preparation message with a quantity threshold is received, counts the number of broadcast binary values ​​of the preparation message that are equal to a first value; when the number of broadcast binary values ​​that are equal to the quantity threshold is equal to the quantity threshold, the delivery block is directly submitted.

[0034] It should be understood that if any of the following conditions are met—that other consensus nodes have not received a fast message from the target consensus node before the timeout, or that a block has been delivered after collecting a threshold number of tags—and there are still blocks that have not been delivered through the linear consensus broadcast protocol, it indicates that entering the fast path has failed and a fallback to the normal path is required. The normal path is invoked for blocks that have not reached consensus. This normal path is implemented by the asynchronous binary consensus protocol. For the asynchronous binary consensus protocol, its input is a binary value, such as 1 or 0 bits. If the output of the asynchronous binary consensus protocol is 1, the delivered block is marked according to the committable tag; otherwise, it indicates that it cannot be committed. To avoid the situation of duplicate block submissions, the normal path is terminated directly when entering the fast path is successful, and vice versa when entering the fast path fails. That is, the fast path is prioritized when the network is good or there is no Byzantine behavior, and consensus can be achieved in two communication rounds. When the fast path cannot reach consensus, it automatically switches to the normal path to ensure that the protocol can maintain security and activity in complex network environments (asynchronous, out-of-order messages, malicious behavior of some nodes).

[0035] It should be noted that, to ensure consistency between the outputs of the fast path and the normal path, this embodiment introduces a preparation phase. This preparation phase is essentially an additional round of message broadcasting, i.e., obtaining the block reception results from other consensus nodes. Based on the block reception results, the consensus nodes broadcast binary values ​​(1 or 0) and corresponding proofs, ensuring input consistency during path switching and avoiding forks or conflicting commits. This prevents malicious nodes from arbitrarily broadcasting interference messages that could cause the system to lose activity. Simultaneously, since there are at least 2f+1 correct nodes in the system, the asynchronous binary consensus protocol can obtain a sufficient number of correct inputs, thus ensuring termination. Furthermore, if the fast path commit is successful, there will be at least n... Since f consensus nodes receive the block, at least one correct node broadcasts the first value during the preparation phase, ensuring the consistency of the asynchronous binary consensus protocol input. Therefore, the blocks finally committed by the fast path and the normal path are the same.

[0036] Understandably, each of the other consensus nodes needs to determine whether it has received a block delivered via the linear consistency broadcast protocol. If so, the broadcast value is the first value, which can be 1. Otherwise, the broadcast value is the second value, which can be 0. It needs to receive a preparation message for the quantity threshold, form a message set, and then determine the broadcast value. For example, when the number of broadcast binary values ​​equals the first value, it indicates that each node broadcasts 1, and the delivered block is directly submitted.

[0037] Furthermore, after the step of counting the number of preparation messages with a broadcast value of the first value when a preparation message with a quantity threshold is received, the method further includes: when the number of preparation messages with a broadcast value of the first value is less than the quantity threshold, obtaining the number of preparation messages with a broadcast value of the second value; when the number of preparation messages with a broadcast value of the second value is less than the quantity threshold, participating in multiple rounds of voting in the asynchronous binary consensus protocol with preparation messages with a broadcast value of the first value as the first input; when the first output after multiple rounds of voting is the same as the first input, submitting the delivery block through the normal path; when the number of preparation messages with a broadcast value of the second value is equal to the quantity threshold, using preparation messages with a broadcast value of the second value as the second input, and when the second output after multiple rounds of voting is the same as the second input, abandoning the submission of the delivery block.

[0038] Understandably, on the one hand, when the number of broadcast values ​​of the first value is less than a threshold and the number of broadcast values ​​of the second value is less than a threshold, it indicates that at least one broadcast is 1. Therefore, a preparation message with a broadcast value of the first value is used as the first input to participate in multiple rounds of voting in the asynchronous binary consensus protocol. The voting results after multiple rounds of voting are then used as the first output. When the first output is the same as the first input, it indicates that a consensus to commit has been reached, and the delivery block is submitted through the normal path. On the other hand, when the number of broadcast values ​​of the second value is equal to the threshold, it indicates that each node broadcasts 0. Therefore, a preparation message with a broadcast value of the second value is used as the second input to participate in multiple rounds of voting in the asynchronous binary consensus protocol. The voting results after multiple rounds of voting are then used as the second output. When the second output is the same as the second input, it indicates that a consensus to abandon is reached, i.e., the submission of the delivery block is abandoned.

[0039] Step S30: If it is detected that the other consensus nodes received a fast message from the target consensus node before the timeout, the correctness of the fast message is verified.

[0040] It should be understood that a Fast message can serve as sufficient proof that a delivered block is committable. Other consensus nodes will verify the correctness of the Fast message after receiving it broadcast by the target consensus node.

[0041] Furthermore, before step S30, the method further includes: counting the current number of pre-fast messages received by the target consensus node; obtaining the total number of consensus nodes and the number of Byzantine nodes, and calculating a quantity threshold based on the total number and the number of Byzantine nodes; when the current number is greater than or equal to the quantity threshold, aggregating the current number of pre-fast messages to obtain fast messages; and broadcasting the fast messages to other consensus nodes through the target consensus node.

[0042] Understandably, before aggregating pre-fast messages from other consensus nodes into fast messages, it's necessary to determine if the current number of pre-fast messages is greater than or equal to a quantity threshold. This threshold needs to be calculated based on the total number of messages and the number of Byzantine nodes. When the total number of consensus nodes is n and the number of Byzantine nodes is f, this quantity threshold can be expressed as n f. Once a sufficient number of pre-fast messages are generated, they can be aggregated into a fast message, which can then be broadcast to other consensus nodes via the target consensus node.

[0043] Step S40: When the verification is successful, the delivery block is marked according to the submittable tag, and the marked delivery block is submitted through the fast path.

[0044] It should be noted that the committable tag refers to the tag that marks the delivery block as "committable". When the verification is successful, the delivery block can be marked according to the committable tag and the marked delivery block can be submitted through the fast path. Since the transaction submitted by the client is included in this interaction block, the transaction is considered to be completed when the interaction block is submitted.

[0045] In this embodiment, when a transaction submitted by a client is detected, the target consensus node packages the transaction and broadcasts the packaged block to other consensus nodes using a linear consistency broadcast protocol to determine the delivery block. When other consensus nodes send pre-fast messages to the target consensus node, their local timeouts are activated. If another consensus node receives a fast message from the target consensus node before the timeout, the correctness of the fast message is verified. If the verification passes, the delivery block is marked with a committable tag, and the marked delivery block is submitted via the fast path. By replacing the conventional reliable broadcast protocol with a linear consistency broadcast protocol, the communication complexity of block broadcasting is reduced. The fast path is prioritized when the network is good or there is no Byzantine fault tolerance, reducing the number of communication rounds and effectively reducing consensus communication overhead and latency.

[0046] In one specific implementation, this application provides steps for broadcasting packaged blocks and determining the delivery blocks using a linear consistency broadcast protocol. Please refer to Figure 2, which is a second flowchart illustrating the asynchronous Byzantine consensus fault-tolerant method based on consistent broadcast and fast path provided in this application embodiment. Step S10 includes steps S101~S104: Step S101, upon detecting a transaction submitted by the client, the transaction is stored in the queue to be packaged.

[0047] It should be noted that the queue to be packaged refers to the queue used to store transactions. This queue can also be called the transaction pool. It is used for subsequent block packaging. When a transaction submitted by a client is detected, it indicates that the target consensus node has received the transaction submitted by the client. At this time, the transaction can be stored in the queue to be packaged.

[0048] Step S102: Select batch transaction data containing the transaction from the queue to be packaged through the target consensus node, and package the batch transaction data.

[0049] Understandably, in order to effectively improve transaction throughput and reduce average transaction costs, this embodiment packages transactions in batches. To this end, the target consensus node selects a batch of transaction data from the queue to be packaged, which includes previously stored transactions, and then packages the selected batch of transaction data into blocks.

[0050] Step S103: Using a linear consensus broadcast protocol, the packaged block is broadcast to other consensus nodes, and the other consensus nodes calculate the hash value of the packaged block, generate a partial threshold signature based on the hash value, and feed back the partial threshold signature to the target consensus node.

[0051] It should be understood that in this embodiment, a linear consistency broadcast protocol is used to replace the conventional reliable broadcast protocol, which significantly reduces the communication overhead of the broadcast phase and reduces the complexity of the broadcast phase from O(n³) to O(n²). This linear consistency broadcast protocol is used to distribute and ensure that all correct consensus nodes eventually receive a consistent delivery block. The linear consistency broadcast protocol consists of three rounds of communication. The first round of communication broadcasts the packaged block. The second round of communication is used to calculate the hash value of the packaged block and carry a partial threshold signature, where the threshold is 2f+1. After receiving 2f+1 voting messages, the target consensus node restores the partial threshold signature. The third round of communication is used to broadcast the complete threshold signature.

[0052] Step S104: Generate a complete threshold signature based on each of the partial threshold signatures, broadcast the complete threshold signature to the other consensus nodes using the linear consistency broadcast protocol, and determine the delivery block based on the verification results of the other consensus nodes.

[0053] Understandably, for the target consensus node, after receiving the partial threshold signatures from other consensus nodes, it can restore the multiple partial threshold signatures into a complete threshold signature. At this point, it performs the final round of communication, that is, it uses the linear consensus broadcast protocol to broadcast the complete threshold signature to other consensus nodes. For other consensus nodes, when they receive and verify the signature, they consider the block to have been "delivered", that is, they determine that the block has been delivered.

[0054] In this embodiment, upon detecting a transaction submitted by a client, the transaction is stored in a queue to be packaged. A target consensus node selects batch transaction data containing the transaction from the queue and packages the batch transaction data. A linear consistency broadcast protocol is used to broadcast the packaged block to other consensus nodes, which calculate the hash value of the packaged block, generate a partial threshold signature based on the hash value, and send the partial threshold signature back to the target consensus node. A complete threshold signature is generated based on each partial threshold signature, and the linear consistency broadcast protocol is used to broadcast the complete threshold signature to the other consensus nodes. The delivery block is determined based on the verification results of the other consensus nodes. By selecting batch transaction data containing the client-submitted transaction from the queue, and then using a three-round linear consistency broadcast protocol to broadcast the packaged block to other consensus nodes, calculate the hash value of the packaged block carrying a partial threshold signature, and broadcast the complete threshold signature to other consensus nodes, the delivery block is determined when the other consensus nodes receive and verify the information. This significantly reduces the communication overhead of the broadcast phase.

[0055] The asynchronous Byzantine consensus fault-tolerant device based on consistent broadcasting and fast path provided in this application is described below. The asynchronous Byzantine consensus fault-tolerant device based on consistent broadcasting and fast path described below can be referred to in correspondence with the asynchronous Byzantine consensus fault-tolerant method based on consistent broadcasting and fast path described above. Please refer to Figure 3. Figure 3 is a schematic diagram of the module structure of the asynchronous Byzantine consensus fault-tolerant device based on consistent broadcasting and fast path provided in an embodiment of this application, including: a determination module T10, used to determine the delivery block by packaging the transaction through the target consensus node and broadcasting the packaged block to other consensus nodes using a linear consistent broadcasting protocol when a transaction submitted by the client is detected.

[0056] The detection module T20 is used to start the local timeout of the other consensus nodes when it detects that the other consensus nodes are sending a pre-fast message to the target consensus node.

[0057] The detection module T20 is also used to verify the correctness of the fast message if it detects that the other consensus node receives a fast message from the target consensus node before the timeout.

[0058] The consensus module T30 is used to mark the delivery block according to the committable tag when the verification is successful, and to submit the marked delivery block through the fast path.

[0059] In this embodiment, when a transaction submitted by a client is detected, the target consensus node packages the transaction and broadcasts the packaged block to other consensus nodes using a linear consistency broadcast protocol to determine the delivery block. When other consensus nodes send pre-fast messages to the target consensus node, their local timeouts are activated. If another consensus node receives a fast message from the target consensus node before the timeout, the correctness of the fast message is verified. If the verification passes, the delivery block is marked with a committable tag, and the marked delivery block is submitted via the fast path. By replacing the conventional reliable broadcast protocol with a linear consistency broadcast protocol, the communication complexity of block broadcasting is reduced. The fast path is prioritized when the network is good or there is no Byzantine fault tolerance, reducing the number of communication rounds and effectively reducing consensus communication overhead and latency.

[0060] It is understood that the detailed functional implementation of each of the above modules can be found in the description of the aforementioned method embodiments, and will not be repeated here.

[0061] It should be understood that the above-described device is used to execute the methods in the above embodiments. The implementation principle and technical effect of the corresponding program modules in the device are similar to those described in the above methods. The working process of the device can be referred to the corresponding process in the above methods, and will not be repeated here.

[0062] Based on the methods in the above embodiments, this application provides an electronic device. Please refer to Figure 4, which is a schematic diagram of the structure of the electronic device provided in this application.

[0063] It should be noted that the system may include: a processor 10, a communications interface 20, a memory 30, and a communication bus 40. The processor 10, communications interface 20, and memory 30 communicate with each other via the communication bus 40. The processor 10 can invoke logical instructions stored in the memory 30 to execute the methods described in the above embodiments.

[0064] Furthermore, the logical instructions in the aforementioned memory 30 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 part 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, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0065] 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.

[0066] 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.

[0067] It is understood that the processor in the embodiments of this application can be a central processing unit, or other general-purpose processors, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, 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.

[0068] 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, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, 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.

[0069] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. Those skilled in the art will readily understand that the above descriptions are merely preferred embodiments of this application and are 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 protection scope of this application.

Claims

1. An asynchronous Byzantine consensus fault-tolerant method based on consistent broadcasting and fast path, characterized in that, include: When a transaction submitted by a client is detected, the transaction is packaged by the target consensus node, and the packaged block is broadcast to other consensus nodes using a linear consistency broadcast protocol to determine the delivery block; when other consensus nodes are detected to send a pre-fast message to the target consensus node, the local timeout of the other consensus nodes is started; if other consensus nodes receive a fast message from the target consensus node before the timeout, the correctness of the fast message is verified. Upon successful verification, the delivery block is marked according to the submittable tag, and the marked delivery block is submitted via the fast path.

2. The method as described in claim 1, characterized in that, The step of determining the delivery block by packaging the transaction through the target consensus node and broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol when a transaction submitted by the client is detected includes: storing the transaction in a queue to be packaged when a transaction submitted by the client is detected; selecting a batch of transaction data containing the transaction from the queue to be packaged by the target consensus node and packaging the batch of transaction data; broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol, and having the other consensus nodes calculate the hash value of the packaged block, generate a partial threshold signature based on the hash value, and feed the partial threshold signature back to the target consensus node; generating a complete threshold signature based on each of the partial threshold signatures, broadcasting the complete threshold signature to the other consensus nodes using the linear consistency broadcast protocol, and determining the delivery block based on the verification results of the other consensus nodes.

3. The method as described in claim 1, characterized in that, Before the step of verifying the correctness of the fast message if it is detected that other consensus nodes have received a fast message from the target consensus node before the timeout, the method further includes: counting the current number of pre-fast messages received by the target consensus node; obtaining the total number of consensus nodes and the number of Byzantine nodes, and calculating a quantity threshold based on the total number and the number of Byzantine nodes; when the current number is greater than or equal to the quantity threshold, aggregating the current number of pre-fast messages to obtain a fast message; and broadcasting the fast message to other consensus nodes through the target consensus node.

4. The method as described in claim 1, characterized in that, After the step of activating the local timeout of the other consensus nodes when a pre-fast message is detected being fed back to the target consensus node, the method further includes: if it is detected that the other consensus nodes have not received a fast message from the target consensus node before the timeout and / or there are still blocks not delivered through the linear consistency broadcast protocol after the delivery blocks have been marked with a quantity threshold, then the method falls back to the normal path corresponding to the asynchronous binary consensus protocol; obtains the block reception results of the other consensus nodes, and generates a preparation message for the other consensus nodes based on the block reception results during the preparation phase; when a preparation message with a quantity threshold is received, counts the number of broadcast binary values ​​of the preparation message that are equal to a first value; when the number of broadcast binary values ​​that are equal to the quantity threshold is equal to the quantity threshold, the delivery block is directly submitted.

5. The method as described in claim 4, characterized in that, After the step of counting the number of preparation messages whose broadcast value is a first value when a preparation message with a quantity threshold is received, the method further includes: when the number of broadcast messages whose broadcast value is the first value is less than the quantity threshold, obtaining the number of broadcast messages whose broadcast value is a second value; when the number of broadcast messages whose broadcast value is the second value is less than the quantity threshold, using preparation messages whose broadcast value is the first value as the first input, participating in multiple rounds of voting in the asynchronous binary consensus protocol; when the first output after multiple rounds of voting is the same as the first input, submitting the delivery block through the normal path; when the number of broadcast messages whose broadcast value is the second value is equal to the quantity threshold, using preparation messages whose broadcast value is the second value as the second input, and when the second output after multiple rounds of voting is the same as the second input, abandoning the submission of the delivery block.

6. The method as described in claim 1, characterized in that, After determining the delivery block by packaging the transaction into a target consensus node and broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol when a transaction submitted by a client is detected, the method further includes: triggering a block retrieval mechanism when any consensus node has a complete threshold signature but lacks local block content; controlling the any consensus node to send block content request information to other consensus nodes based on the triggered block retrieval mechanism; parsing the feedback information upon receiving feedback information from other consensus nodes and verifying the parsed complete threshold signature; and supplementing the any consensus node with the parsed block content upon successful verification, and then sending a pre-fast message through the supplemented consensus node.

7. An asynchronous Byzantine consensus fault-tolerant device based on consistent broadcasting and fast path, characterized in that, include: The determination module is used to determine the delivery block by packaging the transaction into a target consensus node and broadcasting the packaged block to other consensus nodes using a linear consistency broadcast protocol when a transaction submitted by the client is detected. The detection module is used to start the local timeout of the other consensus node when it is detected that the other consensus node is sending a pre-fast message to the target consensus node; the detection module is also used to verify the correctness of the fast message if it is detected that the other consensus node receives a fast message from the target consensus node before the timeout. The consensus module is used to mark the delivery block according to the committable tag when the verification is successful, and to submit the marked delivery block through the fast path.

8. 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-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is run on the processor, it causes the processor to perform the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a processor, the processor causes the processor to perform the method as described in any one of claims 1-6.

Images