Byzantine Fault Tolerance-Based Asynchronous Consensus Methods, Devices, Servers, and Media

Abstract

This disclosure presents embodiments of an asynchronous consensus method, apparatus, electronic device, and medium based on Byzantine Fault Tolerance (BFT). One specific implementation of the method includes: in response to receiving a first number of valid fragment signatures submitted by other consensus nodes, generating a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on a target proposal value and a private key allocated by a threshold signature system; sending the complete signature to other consensus nodes; in response to receiving a second number of complete signatures generated by other consensus nodes, generating a signature sequence, wherein the second number is not less than the first number; submitting the signature sequence and performing an asynchronous binary consensus process to generate an ABA consensus output result corresponding to the signature sequence. This implementation enables the adoption of proposal values ​​from Byzantine nodes, thereby improving the performance of the asynchronous BFT consensus method.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer technology, and more specifically to asynchronous consensus methods, apparatus, servers, and media based on Byzantine fault tolerance. Background Technology

[0002] With the development of blockchain technology, a wide variety of BFT (Byzantine Fault Tolerance) protocols have been designed and used. Most of these protocols rely heavily on assumptions about the underlying network in their design and engineering implementation, such as assuming that messages in the network will arrive within a known time, or that messages will arrive within a known time after a GST (global stabilization time) event. However, these assumptions do not hold true under extreme network conditions. Asynchronous consensus, on the other hand, only needs to guarantee that messages will eventually arrive, without any time limit. Even under poor network conditions, the protocol will not lose its activity. Therefore, asynchronous BFT consensus is considered the most robust BFT protocol.

[0003] However, existing asynchronous BFT consensus protocols often suffer from poor performance due to the excessive number of simultaneously running, random sub-protocol instances, and this problem becomes more pronounced as the node size increases, thus greatly limiting the application of blockchain. Summary of the Invention

[0004] Embodiments of this disclosure present an asynchronous consensus method, apparatus, server, and medium based on Byzantine fault tolerance.

[0005] In a first aspect, embodiments of this disclosure provide an asynchronous consensus method based on Byzantine fault tolerance. The method includes: in response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregating the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on a target proposal value and a private key allocated by a threshold signature system; sending the complete signature to other consensus nodes; in response to receiving a second number of complete signatures generated by other consensus nodes, generating a signature sequence, wherein the second number is not less than the first number; submitting the signature sequence and performing an asynchronous binary agreement (ABA) process to generate an ABA agreement output result corresponding to the signature sequence.

[0006] In some embodiments, the difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes.

[0007] In some embodiments, the method further includes: in response to determining that there is an ABA consensus output that matches a preset value among the generated ABA consensus outputs, determining the target proposal value corresponding to the signature sequence that outputs the preset value the fastest as the consensus output of this round.

[0008] In some embodiments, the method further includes: stopping the execution of the ABA process of other consensus nodes in response to determining that there is an ABA consensus output that matches a preset value in the generated ABA consensus output.

[0009] Secondly, embodiments of this disclosure provide an asynchronous consensus device based on Byzantine fault tolerance. The device includes: an aggregation unit configured to, in response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregate the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on a target proposal value and a private key allocated by a threshold signature system; a sending unit configured to send the complete signature to other consensus nodes; a first generation unit configured to, in response to receiving a second number of complete signatures generated by other consensus nodes, generate a signature sequence, wherein the second number is not less than the first number; and a second generation unit configured to submit the signature sequence and execute an asynchronous binary consensus process to generate an ABA consensus output result corresponding to the signature sequence.

[0010] In some embodiments, the difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes.

[0011] In some embodiments, the apparatus further includes: a determining unit configured to, in response to determining that there exists an ABA consensus output that matches a preset value among the generated ABA consensus outputs, determine the target proposal value corresponding to the fastest signature sequence that outputs the preset value as the consensus output of this round.

[0012] In some embodiments, the apparatus further includes a stopping unit configured to stop executing the ABA process of other consensus nodes in response to determining that there is an ABA consensus output that matches a preset value in the generated ABA consensus output.

[0013] Thirdly, embodiments of this disclosure provide an electronic device comprising: one or more processors; a storage device having one or more programs stored thereon; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method described in any implementation of the first aspect.

[0014] Fourthly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon that, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0015] The embodiments of this disclosure provide an asynchronous consensus method, apparatus, server, and medium based on Byzantine Fault Tolerance (BFT). By combining threshold signature technology with a complete signature obtained by aggregating valid fragment signatures from multiple consensus nodes, and by submitting a signature sequence further generated from a second number of complete signatures and the ABA process, the proposed value with data load is converted into a signature sequence. The validity and legitimacy of the signature sequence are guaranteed by the generation process of the signature sequence and the properties of the RBC protocol, thereby enabling even the proposed value of Byzantine nodes to be adopted, thus improving the effectiveness of the asynchronous BFT consensus method. Attached Figure Description

[0016] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0017] Figure 1 This is an exemplary system architecture diagram to which one embodiment of this disclosure can be applied;

[0018] Figure 2 This is a flowchart of an embodiment of the Byzantine fault-tolerant asynchronous consensus method according to this disclosure;

[0019] Figure 3 This is a schematic diagram of an application scenario of an asynchronous consensus method based on Byzantine fault tolerance according to an embodiment of the present disclosure;

[0020] Figure 4 This is a flowchart of yet another embodiment of the Byzantine fault-tolerant asynchronous consensus method according to this disclosure;

[0021] Figure 5 This is a schematic diagram of a structure of an embodiment of an asynchronous consensus device based on Byzantine fault tolerance according to this disclosure;

[0022] Figure 6 This is a schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0023] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] Figure 1 An exemplary architecture 100 is shown that can be applied to the Byzantine fault-tolerant asynchronous consensus method or the Byzantine fault-tolerant asynchronous consensus device of this disclosure.

[0026] like Figure 1 As shown, system architecture 100 may include consensus nodes 101, 102, 103, and 104 and network 105. Network 105 is used as a medium to provide communication links between consensus nodes 101, 102, 103, and 104. Network 105 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0027] Consensus nodes 101, 102, 103, and 104 participate in consensus through network 105. Typically, consensus nodes 101, 102, 103, and 104 can establish a P2P (point-to-point) connection through network 105 to enable communication between them. Before the consensus process, each consensus node has usually obtained a public-private key pair for identity verification through a PKI (Public Key Infrastructure) system; and has also obtained a public-private key pair for running the threshold signature algorithm.

[0028] Consensus nodes 101, 102, 103, and 104 can be either hardware or software. When consensus nodes 101, 102, and 103 are hardware, they can include, but are not limited to, smartphones, tablets, laptops, desktop computers, and servers providing various services. When terminal devices 101, 102, and 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software programs or software modules (e.g., software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are made here.

[0029] It should be noted that the asynchronous consensus method based on Byzantine fault tolerance provided in the embodiments of this disclosure is generally executed by consensus nodes 101, 102, 103, and 104. Correspondingly, the asynchronous consensus device based on Byzantine fault tolerance is generally set in consensus nodes 101, 102, 103, and 104.

[0030] It should be understood that Figure 1 The number of consensus nodes and networks shown is merely illustrative. Depending on implementation needs, there can be any number of consensus nodes and networks.

[0031] Continue to refer to Figure 2 The diagram illustrates a flow 200 of an embodiment of an asynchronous consensus method based on Byzantine fault tolerance according to this disclosure. This asynchronous consensus method based on Byzantine fault tolerance includes the following steps:

[0032] Step 201: In response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregate the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures.

[0033] In this embodiment, the execution entity of the Byzantine fault-tolerant asynchronous consensus method (such as...) Figure 1 The consensus nodes 101, 102, 103, and 104 shown can receive the first number of valid fragment signatures submitted by other consensus nodes via wired or wireless connections. These valid fragment signatures are generated based on the target proposal value and the private key allocated by the threshold signature system. The other consensus nodes include other nodes that participate in the same consensus process as the aforementioned implementing entity.

[0034] As an example, taking the target proposal value V0 as an example, any node among the consensus nodes in the consensus process participated in by the aforementioned implementing entity can typically submit the proposal value V0 through the Reliable Broadcast protocol (RBC), and can simultaneously perform a fragment signature on the source of the submitted proposal value V0 using the private key allocated by the aforementioned threshold signature system. It can be seen that the aforementioned fragment signature corresponds one-to-one with the consensus node that submitted the target proposal value.

[0035] In this embodiment, in a scenario where multiple RBC protocol proposals are submitted in parallel, the aforementioned execution entity can receive valid fragment signatures submitted by multiple consensus nodes. When the number of received valid fragment signatures reaches the aforementioned first number, the execution entity can aggregate the received first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures. The aforementioned first number is typically greater than the number of Byzantine nodes among the consensus nodes. Therefore, receiving the aforementioned first number of valid fragment signatures means that at least one honest node has submitted the target proposal value V0. Then, based on the RBC protocol, the target proposal value V0 will eventually be submitted by all consensus nodes. Thus, the generated complete signature contains information from the aforementioned first number of valid fragment signatures.

[0036] Step 202: Send the complete signature to other consensus nodes.

[0037] In this embodiment, the executing entity can send the complete signature generated in step 201 to other consensus nodes in various ways. As an example, the executing entity can send the complete signature generated in step 201 to other consensus nodes through the network on which the RBC protocol relies, or it can use a regular network; no limitation is made here.

[0038] Step 203: In response to receiving complete signatures generated by a second number of other consensus nodes, generate a signature sequence.

[0039] In this embodiment, the executing entity can receive complete signatures sent by the other consensus nodes. In response to receiving a second number of complete signatures generated by other consensus nodes, the executing entity can generate a signature sequence in various ways. The second number is typically not less than the first number. For example, the executing entity can aggregate the received second number of complete signatures generated by other consensus nodes to generate a signature sequence. Thus, the generated signature sequence contains information from the second number of complete signatures. Furthermore, each of the second number of complete signatures contains information from the first number of valid fragment signatures.

[0040] It should be noted that, according to the nature of the RBC protocol, when the number of consensus nodes is 3f+1 (where f is the number of Byzantine nodes), each consensus node will eventually submit at least 2f+1 valid proposal values. Therefore, when consensus nodes propose in parallel, each consensus node will receive at least 2f+1 complete signatures from different sources. The generation method of these complete signatures is typically consistent with the method described in step 201 above.

[0041] In some optional implementations of this embodiment, the difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes. For example, the second number can be 2f+1, and the first number can be f+1. Here, f is the number of Byzantine nodes in the consensus nodes.

[0042] Based on the above-mentioned optional implementation methods, this scheme can generate a complete signature using the minimum number of valid fragment signatures, and then generate a signature sequence, thereby maximizing speed while ensuring the effectiveness of the asynchronous consensus method.

[0043] Step 204: Submit the signature sequence and execute the asynchronous binary consistency process to generate the ABA consistency output result corresponding to the signature sequence.

[0044] In this embodiment, firstly, the executing entity can submit the signature sequence generated in step 203 in various ways. As an example, the executing entity can submit the signature sequence based on the various stages included in the RBC protocol. The process of submitting the signature sequence based on the RBC protocol can refer to the RBC process in the Honey Badger BFT algorithm, but the object of submission changes from the proposal value to the signature sequence generated in step 203. Then, the executing entity can execute an asynchronous binary agreement process to generate an ABA (Asynchronous Binary Agreement) agreement output corresponding to the signature sequence.

[0045] It should be noted that the ABA process described above aims to achieve consensus among all consensus nodes on either "0" or "1" in an asynchronous environment. The number of ABA instances that need to be executed in parallel in each round of consensus is usually the same as the number of consensus nodes. The specific process of performing asynchronous binary consensus can be referenced from the ABA process of the "Honey Badger Algorithm," but the signature used as the random source is based on the signature sequence generated in step 203 above, rather than the signature of the consensus node itself.

[0046] In this embodiment, the execution entity can generate ABA consistency output results corresponding to the signature sequence in various ways based on the output results of the parallel ABA instances.

[0047] As an example, when the above 2f+1 ABA instances output "1", the above execution entity can generate "1" as the ABA consistent output result.

[0048] In some optional implementations of this embodiment, the execution entity may further determine the target proposal value corresponding to the fastest signature sequence that outputs the preset value as the consensus output result of this round in response to determining that there is an ABA consensus output result that matches the preset value among the generated ABA consensus output results. Here, the preset value is usually a value representing "true", such as "1".

[0049] Based on the aforementioned optional implementation methods, the signature sequence generated based on threshold signatures ensures that the consensus algorithm remains effective even when only one preset value is output, instead of the original preset number (e.g., 2f+1) of preset values. This significantly accelerates the determination of the consensus output. Furthermore, since the ABA protocol is the most time-consuming sub-protocol in the "Honey Badger Algorithm," the acceleration of the ABA process greatly improves the efficiency of the entire asynchronous consensus method.

[0050] See also Figure 3 , Figure 3This is a schematic diagram illustrating an application scenario of an asynchronous consensus method based on Byzantine fault tolerance according to embodiments of this disclosure. Figure 3 In this application scenario, the consensus nodes include nodes 301, 302, 303, and 304. Node 301 receives valid fragment signatures submitted by nodes 303 and 304, respectively. These valid fragment signatures are generated based on the proposal value V0 and the private keys allocated to nodes 303 and 304 by the threshold signature system. Node 301 then aggregates the received valid fragment signatures from nodes 303 and 304 to generate a complete signature. Node 301 then sends its generated complete signature to nodes 302, 303, and 304. Similarly, nodes 302, 303, and 304 also send their generated complete signatures to other consensus nodes (excluding themselves) following the same steps. Upon receiving the complete signatures from nodes 302, 303, and 304, node 301 can aggregate these complete signatures to generate a signature sequence. Finally, node 301 can submit its generated signature sequence. Similarly, nodes 302, 303, and 304 also submit their generated signature sequences following the steps described above. For the signature sequences submitted by nodes 301, 302, 303, and 304, the ABA process is executed in parallel. When the target number of ABA processes output "1", the ABA process for this round of consensus can be considered complete, and the target proposal value corresponding to the output "1" is determined as the consensus output for this round.

[0051] Currently, one existing technology is the "Honey Badger Algorithm," which directly submits the proposal value from consensus nodes, making it impossible to distinguish whether the proposal value originates from an honest node or a Byzantine node. The method provided in the above-described embodiments of this disclosure combines threshold signature technology with a complete signature obtained by aggregating valid fragment signatures from multiple consensus nodes. By submitting a signature sequence further generated from a second number of complete signatures and the ABA process, the data-loaded proposal value is transformed into a signature sequence. The validity and legitimacy of this signature sequence are guaranteed through its generation process and the properties of the RBC protocol, thus enabling the adoption of proposal values ​​from Byzantine nodes, thereby improving the effectiveness of the asynchronous BFT consensus method.

[0052] Further reference Figure 4 This illustrates a flow 400 of another embodiment of an asynchronous consensus method based on Byzantine fault tolerance. Flow 400 of this Byzantine fault-tolerant asynchronous consensus method includes the following steps:

[0053] Step 401: In response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregate the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures.

[0054] Step 402: Send the complete signature to other consensus nodes.

[0055] Step 403: In response to receiving complete signatures generated by a second number of other consensus nodes, generate a signature sequence.

[0056] Step 404: Submit the signature sequence and execute the asynchronous binary consistency process to generate the ABA consistency output result corresponding to the signature sequence.

[0057] Steps 401-404 above are the same as steps 201-204 in the previous embodiment. The description of steps 201-204 and their optional implementation methods above also applies to steps 401-404, and will not be repeated here.

[0058] Step 405: In response to determining that there is an asynchronous binary consistency output that matches the preset value in the generated asynchronous binary consistency output, stop executing the asynchronous binary consistency process of other consensus nodes.

[0059] In this embodiment, in response to determining that there is a consistent output result matching a preset value among the generated consistent output results, the execution subject of the Byzantine fault-tolerant asynchronous consensus method (e.g., Figure 1 The consensus nodes 101, 102, 103, and 104 shown can stop executing the asynchronous binary consensus process of other consensus nodes. The preset value mentioned above could be, for example, "1".

[0060] In this embodiment, the consensus output result for this round is determined from a preset number (e.g., 2f+1) of preset values ​​to only one preset value, thereby greatly accelerating the determination speed of the consensus output result. Since the ABA protocol is the most time-consuming sub-protocol in the "Honey Badger Algorithm," the acceleration of the ABA process greatly improves the efficiency of the entire asynchronous consensus method.

[0061] from Figure 4As can be seen from the diagram, the process 400 of the Byzantine Fault Tolerance-based asynchronous consensus method in this embodiment embodies the step of stopping the execution of other consensus nodes in response to determining that there is an ABA consensus output that matches a preset value among the generated ABA consensus outputs. Therefore, the scheme described in this embodiment can improve the end marker of the ABA process in this round of consensus from the slowest ABA instance among the preset number (e.g., the aforementioned 2f+1) preset value outputs to the ABA instance that outputs the preset value fastest in the ABA process, shortening the consensus time and thus improving the system throughput (Transactions per Second, TPS) of asynchronous BFT consensus. Furthermore, by effectively reducing the number of executed ABA instances, asynchronous BFT consensus with large-scale consensus nodes becomes possible.

[0062] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of an asynchronous consensus device based on Byzantine fault tolerance, which is similar to... Figure 2 or Figure 4 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0063] like Figure 5 As shown, the Byzantine fault-tolerant asynchronous consensus device 500 provided in this embodiment includes an aggregation unit 501, a sending unit 502, a first generation unit 503, and a second generation unit 504. The aggregation unit 501 is configured to aggregate the first number of valid fragment signatures submitted by other consensus nodes in response to receiving such signatures, to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures. The valid fragment signatures are generated based on the target proposal value and a private key allocated by the threshold signature system. The sending unit 502 is configured to send the complete signature to other consensus nodes. The first generation unit 503 is configured to generate a signature sequence in response to receiving a second number of complete signatures generated by other consensus nodes, wherein the second number is not less than the first number. The second generation unit 504 is configured to submit the signature sequence and execute an asynchronous binary consensus process to generate an ABA consensus output result corresponding to the signature sequence.

[0064] In this embodiment, the specific processing of the aggregation unit 501, the sending unit 502, the first generation unit 503, and the second generation unit 504 in the Byzantine fault-tolerant asynchronous consensus device 500, and the resulting technical effects, can be found in the following references: Figure 2 The relevant descriptions of steps 201, 202, 203 and 204 in the corresponding embodiments will not be repeated here.

[0065] In some optional implementations of this embodiment, the difference between the second number and the first number may not be less than the number of Byzantine nodes in the consensus nodes.

[0066] In some optional implementations of this embodiment, the above-mentioned Byzantine fault-tolerant asynchronous consensus device 500 may further include: a determining unit (not shown in the figure), configured to determine the target proposal value corresponding to the fastest signature sequence that outputs the preset value as the consensus output result of this round in response to determining that there is an ABA consensus output result that matches the preset value in the generated ABA consensus output results.

[0067] In some optional implementations of this embodiment, the above-mentioned Byzantine fault-tolerant asynchronous consensus device 500 may further include: a stopping unit (not shown in the figure), configured to stop executing the ABA process of other consensus nodes in response to determining that there is an ABA consensus output result that matches a preset value in the generated ABA consensus output result.

[0068] The apparatus provided in the above embodiments of this disclosure combines threshold signature technology with a complete signature generated by aggregation unit 501, which is obtained by aggregating valid fragment signatures from multiple consensus nodes. By submitting a signature sequence generated by first generation unit 503 based on a second number of complete signatures and second generation unit 504 executing the ABA process to generate a consistent output result corresponding to the signature sequence, the proposed value with data load is converted into a signature sequence. The validity and legitimacy of the signature sequence are guaranteed by the generation process of the signature sequence and the nature of the RBC protocol. This enables even the proposed value of Byzantine nodes to be adopted, thereby improving the effect of the asynchronous BFT consensus method.

[0069] The following is for reference. Figure 6 It illustrates an electronic device suitable for implementing embodiments of this application (e.g., Figure 1 The diagram below shows the structure of the server or terminal device 600. The terminal device in this embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0070] like Figure 6As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0071] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 6 Each box shown can represent a device or multiple devices as needed.

[0072] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this application.

[0073] It should be noted that the computer-readable medium described in the embodiments of this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the embodiments of this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the embodiments of this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (Radio Frequency), etc., or any suitable combination thereof.

[0074] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: in response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregate the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on the target proposal value and a private key allocated by the threshold signature system; send the complete signature to other consensus nodes; in response to receiving a second number of complete signatures generated by other consensus nodes, generate a signature sequence, wherein the second number is not less than the first number; submit the signature sequence and execute an asynchronous binary consensus process to generate an ABA consensus output result corresponding to the signature sequence.

[0075] Computer program code for performing the operations of embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C", Python, or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0076] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0077] The units described in the embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor, for example, a processor including an aggregation unit, a sending unit, a first generation unit, and a second generation unit. The names of these units do not necessarily limit the unit itself; for example, the aggregation unit can also be described as "a unit that, in response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregates the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on a target proposal value and a private key allocated by a threshold signature system."

[0078] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. An asynchronous consensus method based on Byzantine fault tolerance, comprising: In response to receiving a first number of valid fragment signatures submitted by other consensus nodes, the first number of valid fragment signatures are aggregated to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on the target proposal value and the private key allocated by the threshold signature system; Send the complete signature to other consensus nodes; In response to receiving complete signatures generated by a second number of other consensus nodes, a signature sequence is generated, wherein the second number is not less than the first number; Submit the signature sequence and execute the asynchronous binary consistency ABA process to generate the ABA consistency output result corresponding to the signature sequence.

2. The method according to claim 1, wherein, The difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes.

3. The method according to claim 1, wherein, The method further includes: In response to the determination that there is an ABA consensus output that matches the preset value among the generated ABA consensus outputs, the target proposal value corresponding to the fastest signature sequence that outputs the preset value is determined as the consensus output of this round.

4. The method according to any one of claims 1-3, wherein, The method further includes: In response to the determination that there is an ABA consensus output that matches the preset value in the generated ABA consensus output, the execution of the ABA process of other consensus nodes is stopped.

5. An asynchronous consensus device based on Byzantine fault tolerance, comprising: An aggregation unit is configured to, in response to receiving a first number of valid fragment signatures submitted by other consensus nodes, aggregate the first number of valid fragment signatures to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signatures are generated based on a target proposal value and a private key allocated by a threshold signature system; The sending unit is configured to send the complete signature to other consensus nodes; The first generation unit is configured to generate a signature sequence in response to receiving complete signatures generated by a second number of other consensus nodes, wherein the second number is not less than the first number; The second generation unit is configured to submit the signature sequence and execute an asynchronous binary consistency ABA process to generate an ABA consistency output result corresponding to the signature sequence.

6. The apparatus according to claim 5, wherein, The difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes.

7. The apparatus according to claim 5, wherein, The device further includes: The determining unit is configured to, in response to determining that there is an ABA consensus output that matches a preset value among the generated ABA consensus outputs, determine the target proposal value corresponding to the fastest signature sequence that outputs the preset value as the consensus output of this round.

8. The apparatus according to any one of claims 5-7, wherein, The device further includes: The stop unit is configured to stop executing the ABA process of other consensus nodes in response to determining that there is an ABA consensus output that matches a preset value in the generated ABA consensus output.

9. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-4.

10. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1-4.

Images