WO2023078072A1 - 基于拜占庭容错的异步共识方法、装置、服务器和介质 - Google Patents

基于拜占庭容错的异步共识方法、装置、服务器和介质 Download PDF

Info

Publication number
WO2023078072A1
WO2023078072A1 PCT/CN2022/125639 CN2022125639W WO2023078072A1 WO 2023078072 A1 WO2023078072 A1 WO 2023078072A1 CN 2022125639 W CN2022125639 W CN 2022125639W WO 2023078072 A1 WO2023078072 A1 WO 2023078072A1
Authority
WO
WIPO (PCT)
Prior art keywords
consensus
signature
aba
signatures
nodes
Prior art date
Application number
PCT/CN2022/125639
Other languages
English (en)
French (fr)
Inventor
张爽
Original Assignee
京东科技信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东科技信息技术有限公司 filed Critical 京东科技信息技术有限公司
Publication of WO2023078072A1 publication Critical patent/WO2023078072A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the embodiments of the present disclosure relate to the field of computer technology, and in particular to an asynchronous consensus method, device, server and medium based on Byzantine fault tolerance.
  • BFT Binaryzantine Fault Tolerance, Byzantine Fault Tolerance
  • Embodiments of the present disclosure propose an asynchronous consensus method, device, server and medium based on Byzantine fault tolerance.
  • embodiments of the present disclosure provide an asynchronous consensus method based on Byzantine fault tolerance, the method includes: in response to receiving the first number of valid segment signatures submitted by other consensus nodes, aggregating the first number of valid segment signatures , to generate a complete signature for the proposal source corresponding to the first number of valid fragment signatures, wherein the valid fragment signature is generated based on the target proposal value and the private key assigned by the threshold signature system; the complete signature is sent to other consensus nodes; in response to receiving To the second number of complete signatures generated by other consensus nodes, generate a signature sequence, where the second number is not less than the first number; submit the signature sequence and execute the asynchronous binary agreement (Asynchronous Binary Agreement, ABA) process, generate and signature sequence Corresponding ABA consistency output results.
  • Asynchronous Binary Agreement Asynchronous Binary Agreement
  • the difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes.
  • the method further includes: in response to determining that there is an ABA consistent output result matching a preset value among the generated ABA consistent output results, outputting the target corresponding to the signature sequence with the fastest preset value The proposed value is determined as the consensus output of this round of consensus.
  • the method further includes: in response to determining that there is an ABA consistent output result matching a preset value among the generated ABA consistent output results, stopping execution of the ABA process of other consensus nodes.
  • embodiments of the present disclosure provide an asynchronous consensus device based on Byzantine fault tolerance
  • the device includes: an aggregation unit configured to aggregate the first number of valid fragment signatures submitted by other consensus nodes A number of effective fragment signatures to generate a complete signature for the proposal source corresponding to the first number of effective fragment signatures, wherein the effective fragment signature is generated based on the target proposal value and the private key assigned by the 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 the complete signatures generated by the second number of other consensus nodes, wherein the second number is not less than the first number; the second The generation unit is configured to submit the signature sequence and perform an asynchronous binary consistency process, and generate an ABA consistency output result corresponding to the signature sequence.
  • the difference between the second number and the first number is not less than the number of Byzantine nodes in the consensus nodes.
  • the device further includes: a determining unit configured to, in response to determining that there is an ABA consistent output result matching a preset value among the generated ABA consistent output results, output the one with the fastest preset value
  • the target proposal value corresponding to the signature sequence is determined as the consensus output result of this round of consensus.
  • 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 consistent output result matching a preset value among the generated ABA consistent output results .
  • an embodiment of the present disclosure provides an electronic device, the electronic device includes: one or more processors; a storage device, on which one or more programs are stored; when one or more programs are used by one or more Multiple processors are executed, so that one or more processors implement the method described in any implementation manner of the first aspect.
  • embodiments of the present disclosure provide a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, the method described in any implementation manner in the first aspect is implemented.
  • FIG. 1 is an exemplary system architecture diagram to which an embodiment of the present disclosure can be applied;
  • FIG. 2 is a flowchart of an embodiment of an asynchronous consensus method based on Byzantine fault tolerance according to the present disclosure
  • FIG. 3 is a schematic diagram of an application scenario of a Byzantine fault-tolerant-based asynchronous consensus method according to an embodiment of the present disclosure
  • FIG. 4 is a flow chart of another embodiment of the Byzantine fault-tolerant-based asynchronous consensus method according to the present disclosure
  • FIG. 5 is a schematic structural diagram of an embodiment of an asynchronous consensus device based on Byzantine fault tolerance according to the present disclosure
  • FIG. 6 is a schematic structural diagram of an electronic device suitable for implementing an embodiment of the present disclosure.
  • the asynchronous BFT consensus protocol often has low performance due to the large number of random sub-protocol instances running at the same time, and it becomes more obvious as the node scale increases, thus greatly limiting the application of the blockchain.
  • the Byzantine fault-tolerant-based asynchronous consensus method, device, server, and medium provided by the embodiments of the present disclosure combine the threshold signature technology with the complete signature obtained by aggregating valid fragment signatures of multiple consensus nodes, and pass the second number by submitting
  • the signature sequence generated by a complete signature and the ABA process make the proposed value with data payload converted into a signature sequence, and its validity and legitimacy are guaranteed through the generation process of the signature sequence and the nature of the RBC protocol, thus realizing even Even the proposed values of Byzantine nodes can also be adopted, thereby improving the effect of the asynchronous BFT consensus method.
  • FIG. 1 shows an exemplary architecture 100 to which the Byzantine Fault Tolerance-based asynchronous consensus method or Byzantine Fault-tolerant-based asynchronous consensus device of the present disclosure can be applied.
  • the system architecture 100 may include consensus nodes 101 , 102 , 103 , 104 and a network 105 .
  • the network 105 is used as a medium for providing communication links among the consensus nodes 101 , 102 , 103 , 104 .
  • Network 105 may include various connection types, such as wires, wireless communication links, or fiber optic cables, among others.
  • Consensus nodes 101 , 102 , 103 , 104 participate in consensus through network 105 .
  • the consensus nodes 101, 102, 103, and 104 can establish a P2P (point to point, point-to-point) connection through the network 105, so that they can communicate with each other.
  • P2P point to point, point-to-point
  • each consensus node has usually obtained the public-private key pair used to identify the identity through the PKI (Public Key Infrastructure) system; public-private key pair.
  • Consensus nodes 101, 102, 103, 104 can be hardware or software.
  • the consensus nodes 101, 102, and 103 may include, but are not limited to, smart phones, tablet computers, laptop computers, desktop computers, servers providing various services, and the like.
  • the terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above. It can be implemented as multiple software or software modules (such as software or software modules for providing distributed services), or as a single software or software module. No specific limitation is made here.
  • asynchronous consensus method based on Byzantine fault tolerance provided by the embodiments of the present disclosure is generally executed by consensus nodes 101, 102, 103, and 104. 102, 103, 104 in.
  • a flow 200 of an embodiment of the Byzantine fault-tolerant-based asynchronous consensus method according to the present disclosure is shown.
  • the asynchronous consensus method based on Byzantine fault tolerance includes the following steps:
  • Step 201 in response to receiving the 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 proposed source corresponding to the first number of valid fragment signatures.
  • the executive body of the asynchronous consensus method based on Byzantine fault tolerance can receive the first consensus submitted by other consensus nodes through a wired or wireless connection.
  • a number of valid fragment signatures are generated based on the target proposal value and the private key assigned by the threshold signature system.
  • the above-mentioned other consensus nodes include other nodes that participate in the same consensus process with the above-mentioned executive body.
  • any node among the consensus nodes involved in the above-mentioned consensus process can usually submit the proposed value V0 through the reliable broadcast protocol (RBC, Reliable Broadcast), and at the same time, through the above-mentioned threshold signature system
  • RBC reliable broadcast protocol
  • RNC Reliable Broadcast
  • the execution subject may receive valid fragment signatures submitted by multiple consensus nodes.
  • the execution subject may aggregate the above-mentioned received first number of valid segment signatures to generate a complete proposal source corresponding to the above-mentioned first number of valid segment signatures sign.
  • the above-mentioned first number is usually greater than the number of Byzantine nodes in the consensus nodes. Therefore, when the above-mentioned first number of valid fragment signatures is received, it means that at least one honest node has submitted the above-mentioned target proposal value V0. Then, based on the RBC protocol, the above proposed target value V0 will eventually be submitted by all consensus nodes. Therefore, the above-mentioned generated complete signature includes information of the above-mentioned first number of valid fragment signatures.
  • Step 202 send the complete signature to other consensus nodes.
  • the above-mentioned executive body can send the complete signature aggregated and generated in the above-mentioned step 201 to other consensus nodes in various ways.
  • the above-mentioned executor may send the complete signature aggregated and generated in the above-mentioned step 201 to other consensus nodes through the network on which the above-mentioned RBC protocol depends, or may use a common network, which is not limited here.
  • Step 203 generating a signature sequence in response to receiving the complete signatures generated by the second number of other consensus nodes.
  • the aforementioned execution subject may receive the complete signature sent by the aforementioned other consensus nodes.
  • the execution subject may generate a signature sequence in various ways.
  • the above-mentioned second number is generally not less than the above-mentioned first number.
  • the above execution subject may aggregate the received complete signatures generated by the second number of other consensus nodes to generate a signature sequence. Therefore, the above-mentioned generated signature sequence includes information of the above-mentioned second number of complete signatures.
  • each of the above-mentioned second number of complete signatures includes information of the above-mentioned first number of valid fragment signatures.
  • each consensus node will eventually submit at least 2f+1 valid proposal values.
  • each consensus node will receive at least complete signatures from 2f+1 different sources.
  • the generation method of the above-mentioned complete signature is generally consistent with that described in the above-mentioned step 201 .
  • the difference between the above-mentioned second number and the above-mentioned first number is not less than the number of Byzantine nodes in the consensus nodes.
  • the above second number may be 2f+1
  • the above first number may be f+1.
  • the above f is the number of Byzantine nodes in the consensus node.
  • this scheme can use the minimum number of valid fragment signatures to generate a complete signature, and then generate a signature sequence, and improve the speed as much as possible while ensuring the effectiveness of the asynchronous consensus method.
  • Step 204 submitting the signature sequence and executing an asynchronous binary consistency process to generate an ABA consistency output corresponding to the signature sequence.
  • the execution subject may submit the signature sequence generated in step 203 in various ways.
  • the above-mentioned execution subject may submit the above-mentioned signature sequence based on each stage included in the RBC protocol.
  • the above-mentioned process of submitting the signature sequence based on the RBC protocol can refer to the RBC process in the "HoneyBadger BFT" (HoneyBadger BFT), but the submitted object is changed from the proposed value to the signature sequence generated in the above step 203.
  • the above-mentioned executive body can execute the asynchronous binary consistency process to generate an ABA (Asynchronous Binary Agreement, asynchronous binary agreement) consistency output result corresponding to the signature sequence.
  • ABA Asynchronous Binary Agreement, asynchronous binary agreement
  • the above ABA process is to allow all consensus nodes to reach a consensus on "0" or "1" in an asynchronous environment.
  • the number of ABA instances that need to be executed in parallel for each round of consensus is usually consistent with the number of consensus nodes.
  • the above specific process of implementing asynchronous binary consistency can refer to the ABA process of the "Honey Badger Algorithm", but the signature as a random source is based on the signature sequence generated in the above step 203 rather than the signature of the consensus node itself.
  • the execution subject may generate an ABA consistent output result corresponding to the signature sequence in various ways based on the output result of the ABA instance executed in parallel.
  • the above-mentioned executive body may generate "1" as the ABA consistent output result.
  • the execution subject may also output the preset value the fastest The target proposal value corresponding to the signature sequence of is determined as the consensus output result of this round of consensus.
  • the above-mentioned preset value is usually a value representing "true", for example, may be "1".
  • the signature sequence generated based on the threshold signature it is ensured that the consistency output of the current round of consensus is changed from the original preset number (such as the above 2f+1) preset value output to as long as there are In the case of a preset value output, the validity of the consensus algorithm can still be guaranteed, thus greatly speeding up the determination 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 above-mentioned ABA process greatly improves the efficiency of the entire asynchronous consensus method.
  • FIG. 3 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.
  • consensus nodes include nodes 301 , 302 , 303 , and 304 .
  • Node 301 receives valid fragment signatures submitted by node 303 and node 304 respectively.
  • the above-mentioned effective segment signatures are generated based on the proposed value V 0 and the private keys assigned to the nodes 303 and 304 by the threshold signature system respectively.
  • the node 301 aggregates the received effective fragment signatures sent by the nodes 303 and 304 to generate a complete signature.
  • node 301 sends the full signature it has generated to nodes 302, 303, 304.
  • nodes 302, 303, and 304 also refer to the above steps to send the complete signatures generated by them to other consensus nodes except themselves.
  • the node 301 may aggregate the complete signatures sent by the nodes 302, 303, and 304 to generate a signature sequence.
  • the node 301 can submit the generated signature sequence.
  • nodes 302, 303, and 304 also refer to the above steps to submit their generated signature sequences.
  • the ABA process is executed in parallel.
  • the threshold signature technique is combined with the complete signature obtained by aggregating valid fragment signatures of multiple consensus nodes, and by submitting the signature sequence further generated by the second number of complete signatures and the ABA
  • the process converts the proposed value with data load into a signature sequence, and guarantees its validity and legitimacy through the generation process of the signature sequence and the nature of the RBC protocol, so that even the proposed value of the Byzantine node can be adopted , and then improve the effect of the asynchronous BFT consensus method.
  • FIG. 4 it shows a flow 400 of another embodiment of the Byzantine fault tolerance-based asynchronous consensus method.
  • the process 400 of the Byzantine fault-tolerant asynchronous consensus method includes the following steps:
  • Step 401 in response to receiving the 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 proposed source corresponding to the first number of valid fragment signatures.
  • Step 402 sending the complete signature to other consensus nodes.
  • Step 403 generating a signature sequence in response to receiving the complete signatures generated by the second number of other consensus nodes.
  • Step 404 submitting the signature sequence and executing an asynchronous binary consistency process to generate an ABA consistency output corresponding to the signature sequence.
  • steps 401 to 404 are respectively consistent with the steps 201 to 204 in the preceding embodiments, and the above descriptions for steps 201 to 204 and their optional implementation methods are also applicable to steps 401 to 404, which are not repeated here repeat.
  • Step 405 in response to determining that there is an asynchronous binary consistency output matching the preset value among the generated asynchronous binary consistency output results, stop executing the asynchronous binary consistency process of other consensus nodes.
  • the execution subject of the Byzantine fault-tolerant asynchronous consensus method (such as the consensus node 101 shown in FIG. 1 , 102, 103, 104) can stop executing the asynchronous binary consensus process of other consensus nodes.
  • the aforementioned preset value may be "1", for example.
  • the consistency output of the current round of consensus is changed from the original preset number (such as the above-mentioned 2f+1) preset value output to only one preset value output, thereby greatly speeding up the consistency of the consensus Deterministic speed of output results. Since the ABA protocol is the most time-consuming sub-protocol in the "Honey Badger Algorithm", the acceleration of the above-mentioned ABA process greatly improves the efficiency of the entire asynchronous consensus method.
  • the process 400 of the Byzantine fault-tolerant-based asynchronous consensus method in this embodiment reflects that in response to determining that there is an ABA consistent output result that matches a preset value among the generated ABA consistent output results, Steps to stop the process of executing other consensus nodes. Therefore, the scheme described in this embodiment can improve the end flag of the ABA process of the current round of consensus from the slowest ABA instance among the original preset number (such as the above-mentioned 2f+1) preset value outputs to the slowest ABA instance in the ABA process.
  • the ABA instance that quickly outputs the preset value shortens the consensus time, thereby improving the system throughput (Transaction per Second, TPS) of the asynchronous BFT consensus.
  • TPS Transaction per Second
  • the present disclosure provides an embodiment of a Byzantine fault-tolerant asynchronous consensus device, which corresponds to the method embodiment shown in FIG. 2 or FIG. 4 , the device can be specifically applied to various electronic devices.
  • the Byzantine fault-tolerant-based asynchronous consensus device 500 includes an aggregation unit 501 , a sending unit 502 , a first generating unit 503 and a second generating unit 504 .
  • the aggregation unit 501 is configured to, in response to receiving the first number of valid segment signatures submitted by other consensus nodes, aggregate the first number of valid segment signatures to generate proposal sources corresponding to the first number of valid segment signatures A complete signature, wherein the effective fragment signature is generated based on the target proposal value and the private key assigned by the threshold signature system;
  • the sending unit 502 is configured to send the complete signature to other consensus nodes;
  • the first generating unit 503 is configured to respond to receiving The second number of complete signatures generated by other consensus nodes is used to generate a signature sequence, wherein the second number is not less than the first number;
  • the second generation unit 504 is configured to submit the signature sequence and perform an asynchronous binary consistency process to generate a signature sequence with The ABA consistency output corresponding to the signature sequence.
  • Fig. 2 corresponds to the relevant descriptions of step 201, step 202, step 203, and step 204 in the embodiment, and will not be repeated here.
  • the difference between the second number and the first number may not be less than the number of Byzantine nodes in the consensus nodes.
  • the Byzantine fault-tolerant-based asynchronous consensus device 500 may further include: a determining unit (not shown in the figure), configured to output the ABA consistency output result generated in response to the determination There is an ABA consensus output that matches the preset value, and the target proposal value corresponding to the signature sequence that outputs the fastest preset value is determined as the consensus output of this round of consensus.
  • the Byzantine fault-tolerant-based asynchronous consensus device 500 may further include: a stop unit (not shown in the figure), configured to respond to the generated ABA consistency output result If there is an ABA consistency output that matches the preset value, stop executing the ABA process of other consensus nodes.
  • a stop unit (not shown in the figure), configured to respond to the generated ABA consistency output result If there is an ABA consistency output that matches the preset value, stop executing the ABA process of other consensus nodes.
  • the device provided by the above-mentioned embodiments of the present disclosure combines the threshold signature technology with the complete signature generated by the aggregation unit 501 by aggregating valid fragment signatures of multiple consensus nodes, and passes through the first generation unit 503 according to the second number by submitting A signature sequence generated by a complete signature and the second generation unit 504 executes the ABA process to generate a consistent output result corresponding to the signature sequence, so that the proposed value with the data load is converted into a signature sequence, and through the generation process of the signature sequence and the RBC protocol
  • the nature of the guarantees its validity and legitimacy, so that even the proposed value of the Byzantine node can be adopted, thereby improving the effect of the asynchronous BFT consensus method.
  • FIG. 6 it shows a schematic structural diagram of an electronic device (such as the server or terminal device in FIG. 1 ) 600 suitable for implementing the embodiments of the present disclosure.
  • the terminal equipment in the embodiment of the present disclosure may include but not limited to such as mobile phone, notebook computer, digital broadcast receiver, PDA (personal digital assistant), PAD (tablet computer), PMP (portable multimedia player), vehicle terminal (such as mobile terminals such as car navigation terminals) and fixed terminals such as digital TVs, desktop computers and the like.
  • the electronic device shown in FIG. 6 is only an example, and should not limit the functions and application scope of the embodiments of the present disclosure.
  • an electronic device 600 may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 601, which may be randomly accessed according to a program stored in a read-only memory (ROM) 602 or loaded from a storage device 608. Various appropriate actions and processes are executed by programs in the memory (RAM) 603 . In the RAM 603, various programs and data necessary for the operation of the electronic device 600 are also stored.
  • the processing device 601, ROM 602, and RAM 603 are connected to each other through a bus 604.
  • An input/output (I/O) interface 605 is also connected to bus 604.
  • an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; including, for example, a liquid crystal display (LCD, Liquid Crystal Display) , an output device 607 such as a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609.
  • the communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While FIG. 6 shows electronic device 600 having various means, it should be understood that implementing or having all of the means shown is not a requirement. More or fewer means may alternatively be implemented or provided. Each block shown in FIG. 6 may represent one device, or may represent multiple devices as required.
  • embodiments of the present disclosure include a computer program product, which includes a computer program carried on a computer-readable medium, where the computer program includes program codes for executing the methods shown in the flowcharts.
  • the computer program may be downloaded and installed from a network via communication means 609, or from storage means 608, or from ROM 602.
  • the processing device 601 the above-mentioned functions defined in the methods of the embodiments of the present disclosure are executed.
  • the computer-readable medium described in the embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two.
  • a computer readable storage medium may 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 computer-readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer diskettes, hard disks, 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 of the above.
  • a computer-readable storage medium may 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.
  • a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code therein. Such propagated data signals may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • a computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can transmit, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device .
  • the program code contained on the computer readable medium can be transmitted by any appropriate medium, including but not limited to: electric wire, optical cable, RF (Radio Frequency, radio frequency), etc., or any suitable combination of the above.
  • the above-mentioned computer-readable medium may be included in the above-mentioned electronic device, or may exist independently without being incorporated into the electronic device.
  • the above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by the electronic device, the electronic device: in response to receiving the 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 signature is generated based on the target proposal value and the private key assigned by the threshold signature system; the complete signature is sent to other consensus nodes; generating 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; submitting the signature sequence and performing an asynchronous binary consensus process, generating a signature sequence consistent with Corresponding ABA consistency output results.
  • Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, or combinations thereof, including object-oriented programming languages—such as Java, Smalltalk, C++, Also included are conventional procedural programming languages—such as "C,” the Python language, or similar programming languages.
  • the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer can be connected to the user computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (such as through an Internet service provider). Internet connection).
  • LAN local area network
  • WAN wide area network
  • Internet service provider such as AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
  • each block in a flowchart or block diagram may represent a module, program segment, or portion of code that contains one or more logical functions for implementing specified executable instructions.
  • the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or they may sometimes be executed in the reverse order, depending upon the functionality involved.
  • each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations can be implemented by a dedicated hardware-based system that performs the specified functions or operations , or may be implemented by a combination of dedicated hardware and computer instructions.
  • the units involved in the embodiments described in the present disclosure may be implemented by software or by hardware.
  • the described units may also be set in a processor, for example, may be described as: a processor including an aggregation unit, a sending unit, a first generating unit, and a second generating unit.
  • a processor including an aggregation unit, a sending unit, a first generating unit, and a second generating unit.
  • the names of these units do not constitute a limitation on the unit itself in some cases.
  • the aggregation unit can also be described as "in response to receiving the first number of valid fragment signatures submitted by other consensus nodes, aggregate the first a number of valid fragment signatures to generate a unit of 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 assigned by the threshold signature system".

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

一种基于拜占庭容错的异步共识方法、装置、电子设备和介质。该方法包括：响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对该第一数目个有效片段签名对应的提议来源的完整签名（201），其中，该有效片段签名基于目标提议值和门限签名***分配的私钥生成；将该完整签名发送至其他共识节点（202）；响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列（203），其中，该第二数目不小于该第一数目；提交该签名序列以及执行异步二进制一致性过程，生成与该签名序列对应的ABA一致性输出结果（204）。

Description

基于拜占庭容错的异步共识方法、装置、服务器和介质
本申请要求于2021年11月4日提交的、申请号为202111299133.X、发明名称为“基于拜占庭容错的异步共识方法、装置、服务器和介质”的中国专利申请的优先权，该申请的全文以引用的方式并入本申请。
技术领域
本公开的实施例涉及计算机技术领域，具体涉及基于拜占庭容错的异步共识方法、装置、服务器和介质。
背景技术
随着区块链技术的发展，种类繁多的BFT(Byzantine Fault Tolerance，拜占庭容错)协议被设计和使用。其中，多数协议在设计和工程实现上很大程度依赖于对底层网络的假设，如假设网络中的消息能够在一个已知的时间内到达，或者能够在一个GST(global stabilization time)事件之后，消息在已知的时间内到达。但在极端的网络条件下这些假设并不成立，而异步共识只需保证消息最终能到达，并没有到达时间的限制，即使在恶劣的网络条件下协议也不会丧失活性，因此异步BFT共识被认为是鲁棒性最强的BFT协议。
发明内容
本公开的实施例提出了基于拜占庭容错的异步共识方法、装置、服务器和介质。
第一方面，本公开的实施例提供了一种基于拜占庭容错的异步共识方法，该方法包括：响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名，其中，有效片段签名基于目标提议值和门限签名***分配的私钥生成；将完整签名发送至其 他共识节点；响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列，其中，第二数目不小于第一数目；提交签名序列以及执行异步二进制一致性(Asynchronous Binary Agreement,ABA)过程，生成与签名序列对应的ABA一致性输出结果。
在一些实施例中，上述第二数目与第一数目之差不小于共识节点中拜占庭节点的数目。
在一些实施例中，该方法还包括：响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，将输出预设值最快的签名序列所对应的目标提议值确定为本轮共识的一致性输出结果。
在一些实施例中，该方法还包括：响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，停止执行其他共识节点的ABA过程。
第二方面，本公开的实施例提供了一种基于拜占庭容错的异步共识装置，该装置包括：聚合单元，被配置成响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名，其中，有效片段签名基于目标提议值和门限签名***分配的私钥生成；发送单元，被配置成将完整签名发送至其他共识节点；第一生成单元，被配置成响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列，其中，第二数目不小于第一数目；第二生成单元，被配置成提交签名序列以及执行异步二进制一致性过程，生成与签名序列对应的ABA一致性输出结果。
在一些实施例中，上述第二数目与第一数目之差不小于共识节点中拜占庭节点的数目。
在一些实施例中，该装置还包括：确定单元，被配置成响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，将输出预设值最快的签名序列所对应的目标提议值确定为本轮共识的一致性输出结果。
在一些实施例中，该装置还包括：停止单元，被配置成响应于确 定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，停止执行其他共识节点的ABA过程。
第三方面，本公开的实施例提供了一种电子设备，该电子设备包括：一个或多个处理器；存储装置，其上存储有一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面中任一实现方式描述的方法。
第四方面，本公开的实施例提供了一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面中任一实现方式描述的方法。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：
图1是本公开的一个实施例可以应用于其中的示例性***架构图；
图2是根据本公开的基于拜占庭容错的异步共识方法的一个实施例的流程图；
图3是根据本公开的实施例的基于拜占庭容错的异步共识方法的一个应用场景的示意图；
图4是根据本公开的基于拜占庭容错的异步共识方法的又一个实施例的流程图；
图5是根据本公开的基于拜占庭容错的异步共识装置的一个实施例的结构示意图；
图6是适于用来实现本公开的实施例的电子设备的结构示意图。
具体实施方式
下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与 有关发明相关的部分。
需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
相关技术中，异步BFT共识协议在往往由于同时运行的具有随机性的子协议实例数过多而性能低下，且随着节点规模增大而愈加明显，因而极大地限制了区块链的应用。
本公开的实施例提供的基于拜占庭容错的异步共识方法、装置、服务器和介质，通过门限签名技术与由多个共识节点的有效片段签名聚合得到的完整签名相结合，并通过提交通过第二数目个完整签名进一步生成的签名序列以及ABA过程，使得将具有数据负载的提议值转换为签名序列，并通过签名序列的生成过程和RBC协议的性质保证了其有效性和合法性，从而实现了即使是拜占庭节点的提议值也能够被采纳，进而提高异步BFT共识方法的效果。
图1示出了可以应用本公开的基于拜占庭容错的异步共识方法或基于拜占庭容错的异步共识装置的示例性架构100。
如图1所示，***架构100可以包括共识节点101、102、103、104和网络105。网络105用以在共识节点101、102、103、104之间提供通信链路的介质。网络105可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
共识节点101、102、103、104通过网络105参与共识。通常，共识节点101、102、103、104之间可以通过网络105建立P2P(point to point，点对点)连接，以使彼此之间可以相互通信。在共识过程之前，各共识节点通常已经通过PKI(Public Key Infrastructure，公共密钥基础设施)***获得了用于标识身份的公私钥对；并且已经获得了用于运行门限签名(threshold signature)算法的公私钥对。
共识节点101、102、103、104可以是硬件，也可以是软件。当共识节点101、102、103为硬件时，可以包括但不限于智能手机、平板电脑、膝上型便携计算机、台式计算机和提供各种服务的服务器等等。当终端设备101、102、103为软件时，可以安装在上述所列举的电子 设备中。其可以实现成多个软件或软件模块(例如用来提供分布式服务的软件或软件模块)，也可以实现成单个软件或软件模块。在此不做具体限定。
需要说明的是，本公开的实施例所提供的基于拜占庭容错的异步共识方法一般由共识节点101、102、103、104执行，相应地，基于拜占庭容错的异步共识装置一般设置于共识节点101、102、103、104中。
应该理解，图1中的共识节点和网络的数目仅仅是示意性的。根据实现需要，可以具有任意数目的共识节点和网络。
继续参考图2，示出了根据本公开的基于拜占庭容错的异步共识方法的一个实施例的流程200。该基于拜占庭容错的异步共识方法包括以下步骤：
步骤201，响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名。
在本实施例中，基于拜占庭容错的异步共识方法的执行主体(如图1所示的共识节点101、102、103、104)可以通过有线连接方式或者无线连接方式接收到其他共识节点提交的第一数目个有效片段签名。其中，上述有效片段签名基于目标提议值和门限签名***分配的私钥生成。上述其他共识节点包括与上述执行主体共同参与同一共识过程的其他节点。
作为示例，以目标提议值V0为例，上述执行主体所参与的共识过程的共识节点中的任意节点通常可以通过可靠广播协议(RBC，Reliable Broadcast)递交提议值V0，同时可以通过上述门限签名***所分配的私钥对所提交的提议值V0的来源进行片段签名。可见，上述片段签名与递交目标提议值的共识节点一一对应。
在本实施例中，在多个RBC协议并行提议的场景下，上述执行主体可以接收到多个共识节点提交的有效片段签名。当所接收到的有效片段签名的数目达到上述第一数目时，上述执行主体可以聚合上述接 收到的第一数目个有效片段签名，以生成针对上述第一数目个有效片段签名对应的提议来源的完整签名。其中，上述第一数目通常大于共识节点中拜占庭节点的数目。因而，当接收到上述第一数目个有效片段签名时，意味着至少有一个诚实节点递交了上述目标提议值V0。那么，基于RBC协议，上述目标提议值V0最终一定会被所有共识节点所递交。从而，上述所生成的完整签名中包含了上述第一数目个有效片段签名的信息。
步骤202，将完整签名发送至其他共识节点。
在本实施例中，上述执行主体可以通过各种方式将上述步骤201聚合生成的完整签名发送至其他共识节点。作为示例，上述执行主体可以通过上述RBC协议所依赖的网络将上述步骤201聚合生成的完整签名发送至其他共识节点，也可以采用普通网络，在此不作限定。
步骤203，响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列。
在本实施例中，上述执行主体可以接收上述其他共识节点发送的完整签名。响应于接收到第二数目个其他共识节点生成的完整签名，上述执行主体可以通过各种方式生成签名序列。其中，上述第二数目通常不小于上述第一数目。作为示例，上述执行主体可以将接收到的第二数目个其他共识节点生成的完整签名进行聚合，以生成签名序列。从而，上述所生成的签名序列中包含了上述第二数目个完整签名的信息。而且，上述第二数目个完整签名中的每个完整签名中包含了上述第一数目个有效片段签名的信息。
需要说明的是，根据RBC协议的性质，当共识节点的数目为3f+1时(其中，f为拜占庭节点的数目)，最终每个共识节点会至少递交2f+1个有效的提议值。从而，当共识节点并行提议时，每个共识节点会至少收到对于2f+1个不同来源的完整签名。其中，上述完整签名的生成方式通常与上述步骤201所描述的一致。
在本实施例的一些可选的实现方式中，上述第二数目与上述第一数目之差不小于共识节点中拜占庭节点的数目。作为示例，上述第二数目可以为2f+1，上述第一数目可以为f+1。其中，上述f为共识节 点中拜占庭节点的数目。
基于上述可选的实现方式，本方案可以利用最小数目的有效片段签名生成完整签名，进而生成签名序列，在保证异步共识方法有效性的前提下尽可能提升速度。
步骤204，提交签名序列以及执行异步二进制一致性过程，生成与签名序列对应的ABA一致性输出结果。
在本实施例中，首先，上述执行主体可以通过各种方式提交上述步骤203所生成的签名序列。作为示例，上述执行主体可以基于RBC协议所包括的各阶段提交上述签名序列。其中，上述基于RBC协议提交签名序列的过程可以参考“蜜獾算法”(HoneyBadger BFT)中的RBC过程，但提交的对象由提议值变更为上述步骤203生成的签名序列。而后，上述执行主体可以执行异步二进制一致性过程，生成与签名序列对应的ABA(Asynchronous Binary Agreement，异步二进制一致性)一致性输出结果。
需要说明的是，上述ABA过程即是要在异步环境下让所有共识节点对于“0”或“1”达成共识。每轮共识需要并行执行的ABA实例的数目通常与共识节点的数目一致。上述执行异步二进制一致性的具体过程可以参考“蜜獾算法”的ABA过程，但作为随机源的签名是基于上述步骤203所生成的签名序列而非共识节点自身的签名。
在本实施例中，上述执行主体可以基于上述并行执行的ABA实例的输出结果，通过各种方式生成与签名序列对应的ABA一致性输出结果。
作为实例，当上述2f+1个ABA实例输出“1”，上述执行主体可以生成“1”作为ABA一致性输出结果。
在本实施例的一些可选的实现方式中，上述执行主体还可以响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，将输出预设值最快的签名序列所对应的目标提议值确定为本轮共识的一致性输出结果。其中，上述预设值通常为表征“真”的值，例如可以是“1”。
基于上述可选的实现方式中，通过基于门限签名生成的签名序列， 保证了确定本轮共识的一致性输出结果从原来预设数目(例如上述2f+1)个预设值输出变为只要有一个预设值输出的情况下仍能保证共识算法的有效性，从而大大加快了共识的一致性输出结果的确定速度。而由于ABA协议是“蜜獾算法”中耗时最多的子协议，上述ABA过程的加快极大地提升了整个异步共识方法的效率。
继续参见图3，图3是根据本公开的实施例的基于拜占庭容错的异步共识方法的应用场景的一个示意图。在图3的应用场景中，共识节点包括节点301、302、303、304。节点301接收到节点303和节点304分别提交的有效片段签名。其中，上述有效片段签名分别基于提议值V 0和门限签名***为节点303、304分配的私钥生成。而后，节点301将接收到的节点303、304发送的有效片段签名进行聚合，生成完整签名。之后，节点301将其所生成的完整签名发送至节点302、303、304。同理，节点302、303、304也参照上述步骤向除自身外的其他共识节点发送其所生成的完整签名。响应于接收到节点302、303、304发送的完整签名，节点301可以将上述节点302、303、304发送的完整签名进行聚合，生成签名序列。接下来，节点301可以将其所生成的签名序列进行提交。同理，节点302、303、304也参照上述步骤提交其所生成的签名序列。针对节点301、302、303、304提交的签名序列，并行执行ABA过程。当存在目标数目个ABA过程的输出结果为“1”时，可以认定本轮共识的ABA过程执行完毕，从而将上述输出结果为“1”对应的目标提议值确定为本轮共识的一致性输出结果。
目前，现有技术之一是“蜜獾算法”，由于直接将共识节点的提议值进行提交，导致无法区分提议值的来源是诚实节点还是拜占庭节点。而本公开的上述实施例提供的方法，通过门限签名技术与由多个共识节点的有效片段签名聚合得到的完整签名相结合，并通过提交通过第二数目个完整签名进一步生成的签名序列以及ABA过程，使得将具有数据负载的提议值转换为签名序列，并通过签名序列的生成过程和RBC协议的性质保证了其有效性和合法性，从而实现了即使是拜占庭节点的提议值也能够被采纳，进而提高异步BFT共识方法的效果。
进一步参考图4，其示出了基于拜占庭容错的异步共识方法的又一个实施例的流程400。该基于拜占庭容错的异步共识方法的流程400，包括以下步骤：
步骤401，响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名。
步骤402，将完整签名发送至其他共识节点。
步骤403，响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列。
步骤404，提交签名序列以及执行异步二进制一致性过程，生成与签名序列对应的ABA一致性输出结果。
上述步骤401-步骤404分别与前述实施例中的步骤201-步骤204一致，上文针对步骤201-步骤204及其可选的实现方式的描述也适用于步骤401-步骤404，此处不再赘述。
步骤405，响应于确定所生成的异步二进制一致性输出结果中存在与预设值匹配的异步二进制一致性输出结果，停止执行其他共识节点的异步二进制一致性过程。
在本实施例中，响应于确定所生成的一致性输出结果中存在与预设值匹配的一致性输出结果，基于拜占庭容错的异步共识方法的执行主体(例如图1所示的共识节点101、102、103、104)可以停止执行其他共识节点的异步二进制一致性过程。其中，上述预设值例如可以是“1”。
在本实施例中，确定本轮共识的一致性输出结果从原来预设数目(例如上述2f+1)个预设值输出变为只需要有一个预设值输出，从而大大加快了共识的一致性输出结果的确定速度。而由于ABA协议是“蜜獾算法”中耗时最多的子协议，上述ABA过程的加快极大地提升了整个异步共识方法的效率。
从图4中可以看出，本实施例中的基于拜占庭容错的异步共识方法的流程400体现了响应于确定所生成的ABA一致性输出结果中存在 与预设值匹配的ABA一致性输出结果，停止执行其他共识节点的过程的步骤。由此，本实施例描述的方案可以将本轮共识的ABA过程的结束标志从原来预设数目(例如上述2f+1)个预设值输出中最慢的一个ABA实例改进为ABA过程中最快输出预设值的ABA实例，缩短了共识时间，从而提升了异步BFT共识的***吞吐量(Transaction per Second，TPS)。进而，由于有效地减少了执行的ABA实例数，从而使大规模共识节点的异步BFT共识成为可能。
进一步参考图5，作为对上述各图所示方法的实现，本公开提供了基于拜占庭容错的异步共识装置的一个实施例，该装置实施例与图2或图4所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。
如图5所示，本实施例提供的基于拜占庭容错的异步共识装置500包括聚合单元501、发送单元502、第一生成单元503和第二生成单元504。其中，聚合单元501，被配置成响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名，其中，有效片段签名基于目标提议值和门限签名***分配的私钥生成；发送单元502，被配置成将完整签名发送至其他共识节点；第一生成单元503，被配置成响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列，其中，第二数目不小于第一数目；第二生成单元504，被配置成提交签名序列以及执行异步二进制一致性过程，生成与签名序列对应的ABA一致性输出结果。
在本实施例中，基于拜占庭容错的异步共识装置500中：聚合单元501、发送单元502、第一生成单元503和第二生成单元504的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201、步骤202、步骤203和步骤204的相关说明，在此不再赘述。
在本实施例的一些可选的实现方式中，上述第二数目与第一数目之差可以不小于共识节点中拜占庭节点的数目。
在本实施例的一些可选的实现方式中，上述基于拜占庭容错的异 步共识装置500还可以包括：确定单元(图中未示出)，被配置成响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，将输出预设值最快的签名序列所对应的目标提议值确定为本轮共识的一致性输出结果。
在本实施例的一些可选的实现方式中，上述基于拜占庭容错的异步共识装置500还可以包括：停止单元(图中未示出)，被配置成响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，停止执行其他共识节点的ABA过程。
本公开的上述实施例提供的装置，通过门限签名技术与聚合单元501生成的由多个共识节点的有效片段签名聚合得到的完整签名相结合，并通过提交通过第一生成单元503根据第二数目个完整签名生成的签名序列以及第二生成单元504执行ABA过程生成与签名序列对应的一致性输出结果，使得将具有数据负载的提议值转换为签名序列，并通过签名序列的生成过程和RBC协议的性质保证了其有效性和合法性，从而实现了即使是拜占庭节点的提议值也能够被采纳，进而提高异步BFT共识方法的效果。
下面参考图6，其示出了适于用来实现本公开实施例的电子设备(例如图1中的服务器或终端设备)600的结构示意图。本公开实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图6示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线 604。
通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD，Liquid Crystal Display)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。图6中示出的每个方框可以代表一个装置，也可以根据需要代表多个装置。
特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本公开的实施例的方法中限定的上述功能。
需要说明的是，本公开的实施例所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开的实施例中，计算机可读信号介质可以包括在基带中或者作为载 波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(Radio Frequency，射频)等等，或者上述的任意合适的组合。
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名，其中，有效片段签名基于目标提议值和门限签名***分配的私钥生成；将完整签名发送至其他共识节点；响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列，其中，第二数目不小于第一数目；提交签名序列以及执行异步二进制一致性过程，生成与签名序列对应的ABA一致性输出结果。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的实施例的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”、Python语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图，图示了按照本公开的各种实施例的***、 方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开的实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器，包括聚合单元、发送单元、第一生成单元、第二生成单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，聚合单元还可以被描述为“响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合第一数目个有效片段签名，以生成针对第一数目个有效片段签名对应的提议来源的完整签名的单元，其中，有效片段签名基于目标提议值和门限签名***分配的私钥生成”。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开的实施例中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

  1. 一种基于拜占庭容错的异步共识方法，包括：
    响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合所述第一数目个有效片段签名，以生成针对所述第一数目个有效片段签名对应的提议来源的完整签名，其中，所述有效片段签名基于目标提议值和门限签名***分配的私钥生成；
    将所述完整签名发送至其他共识节点；
    响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列，其中，所述签名序列包含所述第二数目个完整签名的信息，所述第二数目不小于所述第一数目；
    提交所述签名序列以及执行异步二进制一致性ABA过程，生成与所述签名序列对应的ABA一致性输出结果。
  2. 根据权利要求1所述的方法，其中，所述第二数目与所述第一数目之差不小于共识节点中拜占庭节点的数目。
  3. 根据权利要求1所述的方法，其中，所述方法还包括：
    响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，将输出所述预设值最快的签名序列所对应的目标提议值确定为本轮共识的一致性输出结果。
  4. 根据权利要求1-3之一所述的方法，其中，所述方法还包括：
    响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，停止执行其他共识节点的ABA过程。
  5. 一种基于拜占庭容错的异步共识装置，包括：
    聚合单元，被配置成响应于接收到其他共识节点提交的第一数目个有效片段签名，聚合所述第一数目个有效片段签名，以生成针对所述第一数目个有效片段签名对应的提议来源的完整签名，其中，所述 有效片段签名基于目标提议值和门限签名***分配的私钥生成；
    发送单元，被配置成将所述完整签名发送至其他共识节点；
    第一生成单元，被配置成响应于接收到第二数目个其他共识节点生成的完整签名，生成签名序列，其中，所述签名序列包含所述第二数目个完整签名的信息，所述第二数目不小于所述第一数目；
    第二生成单元，被配置成提交所述签名序列以及执行异步二进制一致性ABA过程，生成与所述签名序列对应的ABA一致性输出结果。
  6. 根据权利要求5所述的装置，其中，所述第二数目与所述第一数目之差不小于共识节点中拜占庭节点的数目。
  7. 根据权利要求5所述的装置，其中，所述装置还包括：
    确定单元，被配置成响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，将输出所述预设值最快的签名序列所对应的目标提议值确定为本轮共识的一致性输出结果。
  8. 根据权利要求5-7之一所述的装置，其中，所述装置还包括：
    停止单元，被配置成响应于确定所生成的ABA一致性输出结果中存在与预设值匹配的ABA一致性输出结果，停止执行其他共识节点的ABA过程。
  9. 一种电子设备，包括：
    一个或多个处理器；
    存储装置，其上存储有一个或多个程序；
    当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-4中任一所述的方法。
  10. 一种计算机可读介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如权利要求1-4中任一所述的方法。
PCT/CN2022/125639 2021-11-04 2022-10-17 基于拜占庭容错的异步共识方法、装置、服务器和介质 WO2023078072A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111299133.XA CN116070285A (zh) 2021-11-04 2021-11-04 基于拜占庭容错的异步共识方法、装置、服务器和介质
CN202111299133.X 2021-11-04

Publications (1)

Publication Number Publication Date
WO2023078072A1 true WO2023078072A1 (zh) 2023-05-11

Family

ID=86177503

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/125639 WO2023078072A1 (zh) 2021-11-04 2022-10-17 基于拜占庭容错的异步共识方法、装置、服务器和介质

Country Status (2)

Country Link
CN (1) CN116070285A (zh)
WO (1) WO2023078072A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116455904A (zh) * 2023-06-12 2023-07-18 湖南天河国云科技有限公司 基于异步网络去中心化的区块链共识方法及***
CN116546499A (zh) * 2023-07-06 2023-08-04 北京航空航天大学 一种基于轻量级拜占庭容错的移动终端身份认证方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251007A1 (en) * 2018-02-12 2019-08-15 Ripple Labs Inc. Byzantine agreement in open networks
CN111159288A (zh) * 2019-12-16 2020-05-15 郑杰骞 链式结构数据存储、验证、实现方法、***、装置及介质
CN111342971A (zh) * 2020-02-07 2020-06-26 数据通信科学技术研究所 一种拜占庭共识方法和***
CN112862490A (zh) * 2021-04-26 2021-05-28 北京连琪科技有限公司 一种异步网络下的输出共识方法
CN113507528A (zh) * 2021-07-23 2021-10-15 联想(北京)有限公司 数据处理方法及电子设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251007A1 (en) * 2018-02-12 2019-08-15 Ripple Labs Inc. Byzantine agreement in open networks
CN111159288A (zh) * 2019-12-16 2020-05-15 郑杰骞 链式结构数据存储、验证、实现方法、***、装置及介质
CN111342971A (zh) * 2020-02-07 2020-06-26 数据通信科学技术研究所 一种拜占庭共识方法和***
CN112862490A (zh) * 2021-04-26 2021-05-28 北京连琪科技有限公司 一种异步网络下的输出共识方法
CN113507528A (zh) * 2021-07-23 2021-10-15 联想(北京)有限公司 数据处理方法及电子设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116455904A (zh) * 2023-06-12 2023-07-18 湖南天河国云科技有限公司 基于异步网络去中心化的区块链共识方法及***
CN116455904B (zh) * 2023-06-12 2023-09-05 湖南天河国云科技有限公司 基于异步网络去中心化的区块链共识方法及***
CN116546499A (zh) * 2023-07-06 2023-08-04 北京航空航天大学 一种基于轻量级拜占庭容错的移动终端身份认证方法
CN116546499B (zh) * 2023-07-06 2023-09-15 北京航空航天大学 一种基于轻量级拜占庭容错的移动终端身份认证方法

Also Published As

Publication number Publication date
CN116070285A (zh) 2023-05-05

Similar Documents

Publication Publication Date Title
WO2023078072A1 (zh) 基于拜占庭容错的异步共识方法、装置、服务器和介质
CN110609872B (zh) 用于同步节点数据的方法和装置
US20220239496A1 (en) Blockchain consensus method, device and system
CN110535661B (zh) 基于区块链的业务处理方法、装置、电子设备和存储介质
JP7235930B2 (ja) データ要求を処理するための方法及び装置、電子機器、記憶媒体並びにコンピュータプログラム
WO2023284387A1 (zh) 基于联邦学习的模型训练方法、装置、***、设备和介质
CN111199037A (zh) 登录方法、***和装置
WO2022108527A1 (zh) 模型处理方法、***、装置、介质及电子设备
CN110781373A (zh) 榜单更新方法、装置、可读介质和电子设备
WO2021042714A1 (zh) 用于生成信息的方法和装置
WO2022228067A1 (zh) 语音处理方法、装置和电子设备
CN110705985A (zh) 用于存储信息的方法和装置
CN112486825B (zh) 多泳道环境架构***、消息消费方法、装置、设备及介质
CN114116247A (zh) 基于Redis的消息处理方法、装置、***、服务器和介质
CN112242978B (zh) 一种处理数据的方法和装置
CN111355784A (zh) 一种处理请求信息的方法、装置、介质和电子设备
CN116346885A (zh) 标识信息生成方法、装置、电子设备和计算机可读介质
CN113988992B (zh) 订单信息发送方法、装置、电子设备和计算机可读介质
CN113343259B (zh) 基于sm2的联合签名实现方法、装置、电子设备及存储介质
CN113206738B (zh) 一种数字证书管理方法和装置
CN114780124A (zh) 差分升级方法、装置、介质及电子设备
CN110781523B (zh) 用于处理信息的方法和装置
CN113283891A (zh) 信息处理方法、装置和电子设备
CN114443525A (zh) 一种数据处理***、方法、电子设备及存储介质
CN116226888B (zh) 基于隐私保护的电力数据交互加密方法、***与设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22889097

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE