CN113794694B - Binary consensus method and device based on reliable broadcast - Google Patents
Binary consensus method and device based on reliable broadcast Download PDFInfo
- Publication number
- CN113794694B CN113794694B CN202110984390.0A CN202110984390A CN113794694B CN 113794694 B CN113794694 B CN 113794694B CN 202110984390 A CN202110984390 A CN 202110984390A CN 113794694 B CN113794694 B CN 113794694B
- Authority
- CN
- China
- Prior art keywords
- consensus
- voting
- value
- round
- values
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/46—Secure multiparty computation, e.g. millionaire problem
- H04L2209/463—Electronic voting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
Abstract
The embodiment of the application provides a binary consensus method based on reliable broadcasting, which is characterized in that the binary consensus method is applied to any consensus node in a distributed system, and the method comprises the following steps: for a to-be-consensus proposal of any consensus node, determining an initial vote value corresponding to the to-be-consensus proposal; wherein, the initial voting value is a first voting value or a second voting value; executing the following each round of consensus steps in a circulating manner until a preset stop condition is reached, wherein each round of consensus steps comprises the following steps: broadcasting the polling value of the current round to other nodes in the N common identification nodes by using reliable broadcast RBC protocol broadcast; and determining the consensus situation of the proposal to be consensus based on the received vote values of the current rounds broadcasted by other consensus nodes. By adopting the method, each consensus node broadcasts the vote value through reliably broadcasting the RBC protocol and determines the consensus result based on the vote values broadcast by other consensus nodes, so that each consensus node can quickly achieve consensus on the proposal to be consensus and the safety of the consensus process is improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a binary consensus method and apparatus based on reliable broadcast.
Background
The binary consensus is a main component of the byzantine fault-tolerant protocol (BFT), and the currently known asynchronous byzantine consensus protocols all rely directly or indirectly on the binary consensus, which enables the distributed system to achieve consensus in an asynchronous environment. Meanwhile, the binary consensus can also be used for constructing state machine replication (state machine replication), and further the state machine replication is used for establishing a foundation for the distributed fault-tolerant system. Therefore, the study on the binary consensus is an important research direction in the industry at present.
Disclosure of Invention
The embodiment of the application provides a binary consensus method and device based on reliable broadcasting, and is used for solving the problem of low security of a consensus process in the prior art.
According to a first aspect of the embodiments of the present application, a binary consensus method based on reliable broadcasting is provided, and is applied to any consensus node in a distributed system, where the distributed system at least includes N consensus nodes, where N ≧ 3f +1, and f is an integer greater than 0, and the method includes:
for a to-be-consensus proposal of any consensus node, determining an initial vote value corresponding to the to-be-consensus proposal; wherein, the initial voting value is a first voting value or a second voting value;
executing the following each round of consensus steps in a circulating manner until a preset stop condition is reached, wherein each round of consensus steps comprises:
broadcasting the polling value of the current round to other nodes in the N common identification nodes by utilizing a reliable broadcast RBC protocol;
and determining the consensus situation of the proposal to be consensus based on the received polling values of the current rounds broadcasted by other consensus nodes.
According to a second aspect of the embodiments of the present application, there is provided a binary consensus device based on reliable broadcast, which is applied to any consensus node in a distributed system, where the distributed system at least includes N consensus nodes, where N ≧ 3f +1, and f is an integer greater than 0, the device including:
the processing module is used for determining an initial vote value corresponding to the proposal to be consensus for any consensus node; wherein the initial vote value comprises a first vote value or a second vote value; circularly executing each round of consensus steps until a preset stop condition is reached;
wherein in each round of consensus step:
the communication module is used for broadcasting the polling value of the current round to other nodes in the N common nodes by utilizing a reliable broadcast RBC protocol;
and the processing module is used for determining the consensus situation of the proposal to be consensus based on the received vote values of the current round broadcasted by other consensus nodes.
By adopting the consensus method provided by the embodiment of the application, each consensus node broadcasts the vote value through the reliable broadcast RBC protocol, and determines the consensus result based on the vote values broadcast by other consensus nodes, so that each consensus node can quickly achieve consensus on the proposal to be consensus, and meanwhile, the reliable broadcast RBC protocol is used for broadcasting the vote value, so that malicious nodes can be prevented from forging the vote value to perform malicious action, and the safety of the consensus process is improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic diagram of a consensus node maintaining respective RABA instances in an embodiment of the present disclosure;
fig. 2 is a schematic diagram of another consensus node maintaining respective RABA instances in accordance with an embodiment of the present disclosure;
fig. 3 is a flowchart illustrating a reliable broadcast-based consensus method according to an embodiment of the present disclosure;
fig. 4 is a flowchart illustrating a method for broadcasting a consensus message according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of a reliable broadcast-based consensus device according to an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of an apparatus for configuring a device according to an embodiment of the present disclosure.
Detailed Description
The binary consensus is an important component of a Bzaltin fault-tolerant protocol BFT, and currently known asynchronous Bzaltin consensus protocols all directly or indirectly depend on the binary consensus, so that block chains and other distributed systems can achieve the consensus in an asynchronous environment. Meanwhile, the binary consensus can also be used for constructing state machine replication (state machine replication), and further the state machine replication is used for establishing a foundation for the distributed fault-tolerant system.
In the binary consensus, binary means two values, usually 0 and 1, and each node in the distributed system can agree on one of the two values, which is often of practical significance for the distributed system. Taking the application of the binary consensus to the blockchain network as an example, the data of each node in the blockchain network needs to be kept consistent, if the binary consensus method is utilized, when the consensus achieved by each node for a certain batch of transactions is 1, each node stores the data, and when the consensus achieved by each node for a certain batch of transactions is 0, each node does not store the data, so that the consistency of the data stored by each node is ensured. It can be understood that if the security of the binary consensus process is higher, the attack resistance of the distributed system is stronger and the performance is more excellent, so how to improve the security of the binary consensus is one of the important research directions in the industry at present.
In view of the above problems, the embodiment of the present application provides a binary consensus method based on reliable broadcast, which is applied to any consensus node in a distributed system, where the node broadcasts a vote value through a reliable broadcast RBC protocol, and determines a consensus result based on the received vote values broadcast by other consensus nodes, so that each node in the system achieves consensus, and meanwhile, the security of the consensus process is effectively improved.
The scheme in the embodiment of the application can be implemented by adopting various computer languages, such as object-oriented programming language Java and transliterated scripting language JavaScript.
In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following further detailed description of the exemplary embodiments of the present application with reference to the accompanying drawings makes it clear that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
To facilitate understanding of the contents of the present specification by those skilled in the art, terms referred to in the present specification will be described below.
In this specification, a proposal to be consensus-identified may be understood as data issued by any consensus node, and it is expected that other consensus nodes participate in consensus on the data together, and the vote value is used to represent consensus opinions of the respective consensus nodes on the data, where the vote value includes a first vote value and a second vote value, that is, each consensus node may have two consensus opinions together on the proposal to be consensus-identified, and the first vote value and the second vote value may be represented by 1 and 0, respectively, in one embodiment, and may be represented by other forms and symbols, and this specification does not limit specific forms of the first vote value and the second vote value as long as the specification can be used to distinguish the first vote value and the second vote value.
Taking a blockchain scenario as an example, the to-be-consensus proposal may be a batch of transactions obtained by any consensus node from the local transaction pool, and it is expected that other consensus nodes may receive and store the batch of transactions, and the vote value is used to indicate whether each consensus node agrees to store the to-be-consensus proposal.
In other application scenarios, the proposal to be commonly identified and the vote value may have different practical meanings, which is not limited in the present specification.
As shown in fig. 1, a schematic diagram of a binary consensus instance to be performed by any node in a distributed system,
for each consensus node (including itself), any node in the distributed system determines the consensus result of the proposal to be consensus proposed for the consensus node by using the binary consensus method proposed by the description, such as example ABA in the figure 1 -ABA N Respectively, the schematic diagrams of adopting a binary consensus method ABA (asynchronous binary acquisition) to carry out consensus on N consensus nodes are shown, wherein the ABA 1 The target node carries out binary consensus on the proposal to be consensus, ABA, of the consensus node 1 2 And performing binary consensus on the proposal to be consensus, which is proposed by the target node for the consensus node 2, and so on.
As can be seen from the schematic diagram, when performing consensus on each to-be-consensus proposal, the target node determines an initial vote value (0 or 1) as an input of the binary consensus method, and finally the binary consensus method proposed based on the description also obtains an output, that is, a consensus result (0 or 1) for the to-be-consensus proposal.
Based on the above description, as shown in fig. 3, the present specification proposes a reliable broadcast-based binary consensus method, which is a method performed by any consensus node in a distributed system, and for convenience of description, the consensus node performing the method is referred to as a target node.
The distributed system at least comprises N consensus nodes, wherein the consensus nodes refer to nodes participating in a consensus process, and it can be understood that other nodes not participating in the consensus usually exist in the distributed system, and the nodes only receive and store consensus results of the consensus nodes and do not participate in the consensus process; in addition, when there are too many malicious nodes or byzantine nodes in the system, any consensus method cannot ensure that the consensus nodes in the system achieve consensus, so the specification provides that the distributed system includes N consensus nodes, where f malicious nodes are allowed to exist at most in the N consensus nodes, N is greater than or equal to 3f +1, and f and N are integers greater than 0, for example, when N is 4, f is only 1, and when N is 8, f is 2 or 1. The value of f is preset in this specification to any positive integer corresponding to the value of N. For example, when N is 8, f may be set to 2.
The method is applied to any correct node in a plurality of consensus nodes in a distributed system, and it can be understood that other correct consensus nodes also execute the method asynchronously, and when a target node obtains a consensus result for a to-be-consensus proposal proposed by any consensus node, other correct consensus nodes finally obtain the same consensus result for the to-be-consensus proposal, and the distributed system may be a block chain network or other distributed systems, which is not limited in this specification.
The method comprises the following steps:
s301, aiming at a proposal to be consensus of any consensus node, determining an initial vote value corresponding to the proposal to be consensus; wherein the voting value comprises a first voting value and a second voting value; the initial voting value is the first voting value or the second voting value;
as shown in fig. 1 and the description of fig. 1, the target node determines the consensus result for the candidate consensus proposition of each consensus node, and the consensus process for each candidate consensus proposition is described in fig. 3.
In this step, an initial vote value is determined for the proposal to be consensus, and the initial vote value can be determined according to different data in different application scenarios. For example, in a blockchain network, it may be determined from the fact that a proposal to be consensus is received: if the target node receives the proposal to be consensus-identified (other consensus nodes broadcast by the reliable broadcast RBC protocol), the initial vote value of the proposal to be consensus-identified is determined to be the first vote value, and if the proposal to be consensus-identified of N-f consensus nodes has been determined to be received and the binary consensus method proposed in the present specification has been performed for the N-f proposals to be consensus respectively to obtain consensus results, the initial vote value of the proposal to be consensus-identified that has not been received can be set to be the second vote value, and the consensus process starts to be performed. In other application scenarios, the initial vote value of the proposal to be consensus may also be determined from different data. In this specification, the first vote value is 1, and the second vote value is 0. In S301, a unique initial vote value may be determined for each proposal to be consensus.
Fig. 2 is a schematic diagram of an example maintained by each consensus node when the consensus nodes achieve consensus based on the binary consensus method proposed in this specification in a blockchain network.
As can be seen from the figure, when N consensus nodes coexist in a blockchain network, any consensus node needs to maintain an example of N pairs of RBC + ABA, where ABA is a binary consensus method based on reliable broadcasting proposed by the present specification, and a target node triggers to start triggering an ABA process for a certain consensus node after receiving a candidate consensus proposal broadcast by a reliable broadcast RBC protocol by the certain consensus node. For example, after the target node receives the proposal of waiting consensus broadcasted by the consensus node 1 through the reliable broadcast RBC protocol, i.e. ABA 1 (to be proposed for consensus node 1Binary consensus proposed by consensus) is set to 1 (first vote value) and the binary consensus method proposed in this specification begins to be performed. Under the condition that N-f consensus proposals to be consensus, which are of the consensus nodes, are received, after the ABA process is executed according to the N-f consensus proposals to obtain a consensus result of 1, setting the input of the residual f ABAs to be consensus proposals to be 0, and starting to execute the consensus process, namely the ABA process.
In the above manner, the consensus node can determine the initial vote value of each proposal to be consensus.
After S301 is executed, the following steps of recognizing together may be executed in a loop until a preset stop condition is reached, where each step of recognizing together includes:
s302, broadcasting the voting value of the current round to other nodes in the N common nodes by using a reliable broadcast RBC protocol;
and S303, determining the consensus condition of the proposal to be consensus based on the received vote values of the current round broadcasted by other consensus nodes.
The consensus method proposed in the present specification is performed in consensus rounds, each round includes a stage of interacting vote values with other consensus nodes, and a stage of determining consensus results based on the results of the interaction after the interaction is completed, i.e., S302 and S303.
S302 and S303 are explained in detail below:
in S302, the target node may broadcast the local vote value to other consensus nodes, and receive the vote values broadcast by other consensus nodes. In order to improve security, and avoid malicious nodes from intentionally tampering the vote value or pretending to broadcast the vote value by other consensus nodes, each consensus node may broadcast the local vote value by using a reliable broadcast RBC protocol. The reliable broadcast RBC protocol can ensure that the target node can reliably send messages to all the consensus nodes in the network and that the following properties are met: consistency (agent), that is, any two correct nodes receive the same message from the source node; uniformity (Totality), as long as one node receives a message from a source node, all correct nodes can eventually receive the message; activity (Validity), if the source node is correct, all correct nodes must receive messages that are identical to the messages sent by the source node. Specific implementations of the reliable broadcast RBC protocol can be found in the related art and will not be described in detail here. In this embodiment, various specific implementation manners may be adopted to implement the reliable broadcast RBC protocol, and this embodiment is not limited in this embodiment.
The voting value is broadcast by adopting a reliable RBC protocol broadcasting mode, and compared with the common broadcast, the safety of the consensus process can be effectively improved.
In this specification, in S302, that is, in each round of consensus, the target node broadcasts a third vote value, where the vote value broadcasted for the first time is referred to as a pre-vote value, the vote value broadcasted for the second time is referred to as a main vote value, and the vote value broadcasted for the third time is referred to as a final vote value, where in the first round of consensus, the initial vote value is the pre-vote value.
In this specification, when the target node broadcasts the vote value three times, the reliable broadcast RBC protocol may be used for broadcasting.
In addition, considering that broadcasting through a reliable broadcast RBC protocol takes longer time compared with ordinary broadcasting, the description proposes that reliable broadcast RBC can be adopted only when a vote value is broadcast for the third time in each round of consensus, that is, the reliable broadcast RBC protocol can be adopted to broadcast when a final vote value is broadcast, and ordinary broadcasting forms are adopted when the rest two times of broadcasting.
The target node may specifically execute the method described in fig. 4 to complete S302:
s401, broadcasting the pre-voting value of the round to other consensus nodes;
if the initial round of consensus is available, the target node may determine the pre-vote value according to the method described above, that is, the initial vote value is the pre-vote value in the initial round of consensus. If the initial round is not known, the method for determining the pre-voting value of the round can refer to the description part about S303 below, and will not be described in detail here.
Target nodeThe point may add the locally determined pre-vote value to the first consensus message and transmit the first consensus message to other consensus nodes in the distributed system over the authentication channel. In one embodiment, the first common identity message may be bval r And (3) the message in the format, wherein r is the number of the common identification rounds, the first round is 0, and the increment is carried out by taking 1 as a step length.
S402, determining a main voting value of the current round based on the pre-voting values of the current round broadcast by other consensus nodes, and broadcasting the determined main voting value to other consensus nodes;
it can be understood that all correct nodes in the distributed system execute the steps executed by the target node asynchronously, that is, other consensus nodes also send the first consensus message including the pre-vote value; at this time, the target node receives the first consensus message sent by other consensus nodes, and further resolves the pre-vote value.
In one embodiment, if the target node receives f +1 first consensus messages in the current consensus round and analyzes f +1 pre-vote values, namely the first consensus messages exceeding the number of malicious nodes, if the f +1 pre-vote values are the same and different from the pre-vote value broadcast in the local round, the target node modifies the local pre-vote value into the vote value corresponding to the f +1 pre-vote values in the local round and broadcasts the modified pre-vote value again. For example, if the target node receives f +1 bvals r And (2) messages, wherein f +1 pre-vote values carried in the f +1 messages are all 1, and the pre-vote value which has been broadcast once through the first consensus message in the current round of consensus of the target node is 0, which is different from the f +1 pre-vote values, so that the local pre-vote value in the current round of consensus can be modified to be 1, and the pre-vote value with the value of 1 is broadcast through the first consensus message again. This step is intended to allow the local node to correct the local pre-vote value.
In this step, the target node may add, to the voting set of the current round, the voting value corresponding to the 2f +1 current round of pre-voting values when receiving the 2f +1 first consensus messages, that is, the 2f +1 current round of pre-voting values, broadcast by other consensus nodes, and the 2f +1 current round of pre-voting values are all the same; and determines the value that was first added to the current round of voting sets as the current round of master voting values.
For example, the target node receives 2f +1 first consensus messages, analyzes the received first consensus messages, and determines that the pre-vote values carried in the received first consensus messages are all 1, so that the pre-vote value 1 may be added to the round voting set bset r If it is determined that 1 is the first to be added to the voting set bset at this time r And if the value is the median value, determining that 1 is the main voting value.
In this way, the received main vote value may be determined based on the pre-vote value, and after the main vote value is determined, the main vote value may be broadcast through the second consensus message.
And S403, determining a final vote value of the current round based on the main vote values of the current round broadcast by other consensus nodes, and broadcasting the determined final vote value to other consensus nodes by using a reliable broadcast RBC protocol.
In this step, the target node may add the master vote value to the second consensus message aux r The target node may also receive the main vote value broadcast by other common identification nodes, and in order to avoid that a malicious node intentionally sends a false vote value, the target node may perform validity verification on the received main vote value in its turn based on a polling set in its turn, specifically, after receiving the main vote value broadcast by any common identification node, determine whether the main vote value is in the polling set in its turn locally, if so, indicate that the second common identification message is legal, that is, the main vote value carried by the second common identification message is legal, and if not, indicate that the main vote value carried by the second common identification message is illegal.
Under the condition that the N-f main vote values in the legal round are received, the final vote value can be determined based on the N-f main vote values in the legal round, and the method specifically includes: if the main voting values of the N-f legal main voting rounds are the same, determining the voting values corresponding to the main voting values of the N-f legal main voting rounds as final voting values; if the N-f legal main voting values in the current round are not all the same, the final voting value is determined to be a predefined value different from the first voting value and the second voting value.
For example, if the received N-f legal primary vote values are all 1, the final vote value is determined to be 1. In another example, if some of the received N-f legal primary vote values are 1, and some are 0, the final vote value is determined to be x (, which is a predefined value).
After the final vote value is determined, the final vote value may be broadcast to other consensus nodes using the reliable broadcast RBC protocol, and in this step, the reliable broadcast RBC protocol may be implemented based on various implementation manners.
In addition, in order to further improve the security and achieve unconditional security or information theory security, a reliable broadcast RBC protocol without unconditional security may be used to broadcast the third consensus message, for example, a Bracha's broadcast RBC protocol may be used, and the reliable broadcast RBC protocol is used to broadcast, so that the security of the consensus process is further improved no matter how strong the computation capability of the adversary is or cannot be cracked.
The above-mentioned contents related to fig. 4 and the related parts are the process of broadcasting the vote value in S302.
In S303, the following method may be specifically executed:
in this step, specifically, the consensus result of the proposal to be consensus is determined based on the received final vote value of the current round broadcast by the other consensus nodes using the reliable broadcast RBC protocol, before that, the validity of the received final vote value still needs to be verified by using the current round voting set, which may be that when the received final vote value is 0 or 1, if the final vote value is determined to be in the local current round voting set, the final vote value is determined to be legal, otherwise, the final vote value is determined to be illegal. If the received final voting value is a (predefined value), if the local current round voting set comprises the first voting value 1 and the second voting value 0, the final voting value is determined to be legal, otherwise, the final voting value is determined to be illegal.
After the third consensus information, namely the final vote value, is subjected to validity verification, the received final vote value is favorable for determining the consensus condition under the condition that the final vote values of the N-f legal current rounds are received.
Specifically, under the condition that N-f legal current-round final vote values are received, if the N-f current-round final vote values are all the same and are the first vote value or the second vote value, the vote value corresponding to the N-f current-round final vote values is determined as the consensus result of the proposal to be identified, and the vote value corresponding to the N-f current-round final vote values is determined as the pre-vote value of the next consensus.
For example, if the final vote values of the received N-f legal rounds are all 1, the 1 is determined as the consensus result of the to-be-consensus proposal. After the consensus result is obtained, the target node still participates in next round of consensus, and 1 can be determined as a pre-vote value of the next round of consensus.
In addition, if the final voting values of the N-f legal rounds are not all the same, and f +1 legal rounds have the same final voting value and are the first voting value or the second voting value, determining the voting value corresponding to the f +1 legal rounds as the pre-voting value commonly identified in the next round;
for example, if f +1 of the received N-f legal current-round final vote values is 1, the target node determines that the current round does not obtain the consensus result of the to-be-consensus-offered, so that the next round of consensus is to be performed, determines 1 as the pre-vote value of the next round of consensus, and starts to perform the next round of consensus.
In addition, if f +1 identical voting values do not exist in the final voting values of the N-f legal current rounds, a local coin throwing value is randomly determined, and the local coin throwing value is determined as a pre-voting value identified in the next round, wherein the local coin throwing value is randomly determined by the target node and can be the first voting value or the second voting value.
For example, if there are no f +1 votes in the N-f legal current rounds of final votes that are the same, the target node determines that the current round does not obtain the consensus result of the proposal to be consensus, and therefore, to execute the next round of consensus, the target node randomly determines the local coin throwing value, determines the local coin throwing value as the pre-cast value of the next round of consensus, and starts to execute the next round of consensus. In the step, each consensus node determines the local money throwing value, and does not need to interact with other consensus nodes to obtain the public money throwing value, so that any encryption mechanism or encryption algorithm is not needed.
The above-mentioned S302-S303 are processes executed by each round of consensus, and when the preset stop condition is not reached, the processes of S302-S303 are executed in a loop, where the preset stop condition may be that it is determined that the consensus result of the proposal to be consensus has been obtained by the previous round of consensus, and the final vote value has been sent by the current round; and a stop instruction sent by a user can be received.
In addition, any node can only obtain one consensus result for one pending consensus proposal, and after obtaining the consensus result, the node can also participate in the next round of consensus, but can not obtain the consensus result again, that is, if any node obtains the consensus result for one pending consensus proposal in the current round of consensus, the node in the next round of consensus only performs S302, but not S303.
It can be understood that, in each round of consensus process in this specification, three kinds of messages are respectively used for broadcasting the pre-vote value, the main vote value, and the final vote value, so as to enable each consensus node to determine the type of the received message to distinguish different types of vote values, and this specification does not limit the specific type of each message.
The method is executed by any correct node in the consensus nodes, and other correct consensus nodes also execute the method asynchronously. The nodes carry out consensus operation according to consensus rounds, wherein in each consensus round, the nodes only need to broadcast the consensus messages for three times, wherein at least the broadcast consensus message for the third time adopts a reliable broadcast RBC protocol for broadcasting, the safety of the consensus process can be effectively ensured, the probability of ending each round is 1/2, and therefore, after k consensus rounds, the probability of the consensus among the nodes is 1- (1/2) k 。
In addition, in the above consensus method, when each consensus node does not reach the consensus in one round of consensus, the local rejection value is randomly determined as the pre-vote value of the next round of consensus, and there is no need to use cryptography to interact with other consensus nodes to generate a public rejection value (there is no need to use a cryptography principle to perform multiple interactions to obtain one common rejection value).
After reaching consensus for the consensus proposals made for each consensus node, the correct consensus nodes get the same consensus result, either 1 or 0, and after reaching consensus for all consensus proposals made for all consensus nodes, a sequence comprising 0 and 1 is obtained. Further, the corresponding transaction can be executed based on the sequence, and still take a blockchain network as an example, in which a 0 or 1 is used to indicate whether to pack the corresponding consensus proposal into blocks. For example, the consensus suggestion provided by the consensus node 1 is P1, the consensus suggestion provided by the consensus node 2 is P2, the consensus suggestion provided by the consensus node 3 is P3, the consensus suggestion provided by the consensus node 4 is P4, after consensus is performed by using the above consensus method, consensus results are obtained for P1-P4, respectively, and then four consensus results are obtained to form a 01 sequence, for example, the obtained sequence is (1,1,1,0), the achieved consensus results are that all nodes pack P1, P2, and P3 into blocks and store the blocks in the local non-storage P4, that is, each consensus node performs consistency processing on each consensus suggestion according to the consensus results, thereby ensuring data consistency of each consensus node.
A specific embodiment of the consensus method proposed in the present specification is described below from a code implementation perspective:
the pseudo code is as follows:
1 initialization r ← 0
2 event (v) pro input )
3 setting iv 0 ←v input
4 turn on r 0 round
Round 5 the protocol was as follows:
6 first of allEntering a first stage of broadcasting a pre-vote r (iv r ) Message
If receives the pre-vote of the current wheel pair v from the f +1 copies r (v)
7 If the local party does not broadcast the pre-vote of the v, the pre-vote is broadcast r (v)
8 If receives the pre-vote of the current pair v from 2f +1 copies r (v)
9 will bset r ←bset r ∪{v}
10 when gathering
Enter the second stage
11 If does not broadcast the main vote of the local wheel to v, then the main-vote is broadcast r (v) Where v e bset r
The 12 If receives N-f main votes main-votes r (b) In which b e bset r Time of flight
13 If receives N-f main voting messages for the same v, namely all main-votes r (v)
14 RBC broadcasts final vote-vote r (v)
15 else
Final vote-vote of 16 RBC broadcast r (*)
17 If RBC-deliverer N-f final voting messages,
the 18 If receives N-f final voting messages for the same v, namely all final-votes r (v)
19 decide v
20 else if over f +1 final vote messages for the same v
21 iv r+1 ←v
22 else
23 c←Random()
24 iv r+1 ←c
25 r←r+1
In the above pseudo code:
each round is divided into three stages:
first stage
(1) Copy p i Input iv for its r-th round r Broadcast pre-vote r (iv r ) Wherein iv is r ∈{0，1}。
(2) When the copy p i F +1 pre-votes are received for the same value v in the same round number r r (v) And no prior pre-votes for v in r rounds have been broadcast, copy p i The pre-vote is broadcast.
(3) When the copy p i 2f +1 pre-votes are received for the same value v in the same round number r r (v) Then v is inserted into the set bset r Wherein bset r Is a set consisting of 0 and 1.
Second stage
(1) When set bset r Not null, copy p i Fetch bset r As v, broadcasts the main vote main-vote r (v) In that respect A correct copy is accepted by the main vote-vote r (v) Set bset that has been inserted locally if and only if v had previously been inserted r In (1).
(2) When the copy p i Receiving main votes main-votes from N-f different copies r () And entering the third stage.
The third stage
(1) When the copy p i Receiving N-f main votes of the same v in the same round number r r (v) At message time, r-broadcast final vote final-vote for v in r round r (v) Otherwise copy p i r-final vote final-vote broadcast in r round r (. 1) wherein
{0, 1} is a symbol distinguished from 0 and 1.
Final voting final-vote r () For copy p i It is effective only in the following cases:
for a vote final-vote r (v) Copy p i V has been inserted into bset r
For final-vote r (. about.), copy p i Bset of r Containing O and 1
(2) When the copy p i r-deliverer N-f final votes
A. If the N-f final votes for the same v in the same round number r, determining the v, and taking the v as the input of the next round;
B. if more than f +1 final votes for the same v in the same round number r exist, taking v as the input of the next round;
C. otherwise, a random number is generated as the input of the next round.
As shown in fig. 5, corresponding to the foregoing binary consensus method based on reliable broadcast, the present specification further provides a binary consensus device based on reliable broadcast, where the binary consensus device is applied to any consensus node in a distributed system, where the distributed system at least includes N consensus nodes, where N ≧ 3f +1, and f is an integer greater than 0, and the device includes:
a processing module 510, configured to determine, for a to-be-consensus proposal of any consensus node, an initial vote value corresponding to the to-be-consensus proposal; wherein the initial vote value comprises a first vote value or a second vote value; circularly executing the following consensus steps in each round until a preset stop condition is reached;
in each round of consensus:
a communication module 520, configured to broadcast the vote value of the current round to other nodes in the N common nodes by using reliable broadcast RBC protocol broadcast;
and the processing module 510 determines the consensus situation of the proposal to be consensus based on the received vote values of the current round broadcasted by other consensus nodes.
In an embodiment, the communication module 520 is specifically configured to broadcast the current round of pre-voting values to other consensus nodes; the processing module 510 is specifically configured to determine a main vote value of the current round based on the pre-vote values of the current round broadcast by the other consensus nodes; the communication module 520 is specifically configured to broadcast the determined master vote value to other consensus nodes; the processing module 510 is specifically configured to determine a final vote value of the current round based on the main vote values of the current round broadcast by other consensus nodes; the communication module 520 is specifically configured to broadcast the determined final vote value to other consensus nodes using a reliable broadcast RBC protocol.
In one embodiment, the reliable broadcast RBC protocol is an unconditionally secure reliable broadcast RBC protocol.
In an embodiment, the processing module 510 is specifically configured to, when f +1 local round pre-vote values broadcast by other common identification nodes are received, where the f +1 local round pre-vote values are all the same and different from the local round pre-vote value broadcast, modify the local pre-vote value to a vote value corresponding to the f +1 local round pre-vote values, and broadcast the modified pre-vote value again.
In an embodiment, the processing module 510 is specifically configured to, when 2f +1 current round of pre-vote values broadcast by other consensus nodes are received and the 2f +1 current round of pre-vote values are all the same, add vote values corresponding to the 2f +1 current round of pre-vote values to a current round of voting set; the value that was first added to the current round of voting sets is determined to be the current round of master voting value.
In an embodiment, the processing module 510 is specifically configured to perform validity verification on the received main vote value of the current round based on the current round voting set; and under the condition that N-f main voting values in the legal local round are received, determining a final voting value based on the N-f main voting values in the legal local round.
In an embodiment, the processing module 510 is specifically configured to determine, as a final vote value, a vote value corresponding to the N-f main vote values in the legal round if the N-f main vote values in the legal round are the same; and if the main voting values of the N-f legal current rounds are not all the same, determining that the final voting value is a predefined value different from the first voting value and the second voting value.
In an embodiment, the processing module 510 is specifically configured to determine a consensus situation of the to-be-consensus proposal based on the received final vote value of the current round broadcasted by the other consensus nodes using the reliable broadcast RBC protocol.
In an embodiment, the processing module 510 is specifically configured to perform validity verification on the received current round final vote value based on the current round vote set;
under the condition that N-f legal local-round final voting values are received, if the N-f local-round final voting values are the same and are the first voting value or the second voting value, determining the voting value corresponding to the N-f local-round final voting values as the consensus result of the proposal to be consensus, and determining the voting value corresponding to the N-f local-round final voting values as the pre-voting value for the next consensus.
In one embodiment, the processing module 510 is further configured to determine, if the N-f legal final vote values in the current round are not all the same, and f +1 current final vote values in the current round are the same and are the first vote value or the second vote value, a vote value corresponding to the f +1 current final vote value as a pre-vote value identified in a next round; if f +1 identical voting values do not exist in the final voting values of the N-f legal local rounds, a local money throwing value is randomly determined, the local money throwing value is a first voting value or a second voting value, and the local money throwing value is determined as a next round of consensus pre-voting value.
The implementation processes of the functions and actions of each component in the above device are specifically described in the implementation processes of the corresponding steps in the above method, and are not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described apparatus embodiments are merely illustrative. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the present specification. One of ordinary skill in the art can understand and implement it without inventive effort.
Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the aforementioned method when executing the program. The method includes at least the method described above and shown in fig. 3.
Fig. 6 is a schematic diagram illustrating a more specific hardware structure of a computing device according to an embodiment of the present disclosure, where the computing device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component within the device (not shown) or may be external to the device to provide corresponding functionality. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present specification also provide a computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the foregoing method. The method includes at least the method described above and shown in fig. 3.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to realize the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.
Claims (10)
1. A binary consensus method based on reliable broadcasting is characterized by being applied to any consensus node in a distributed system, wherein the distributed system at least comprises N consensus nodes, N is not less than 3f +1, and f is an integer greater than 0, and the method comprises the following steps:
for a to-be-consensus proposal of any consensus node, determining an initial vote value corresponding to the to-be-consensus proposal; the proposal to be consensus provides data for the consensus node and expects other consensus nodes to perform consensus; the voting value is used for expressing the consensus opinion to be treated by each consensus node; the initial voting value is the first voting value or the second voting value;
executing the following each round of consensus steps in a circulating manner until a preset stop condition is reached, wherein each round of consensus steps comprises:
broadcasting the pre-voting value of the round to other consensus nodes; if f +1 local round pre-voting values broadcasted by other consensus nodes are received, wherein the f +1 local round pre-voting values are the same and different from the local round pre-voting values broadcasted, modifying the local pre-voting values into voting values corresponding to the f +1 local round pre-voting values, and broadcasting the modified pre-voting values again;
determining a main voting value of the current round based on the pre-voting values of the current round broadcast by other consensus nodes, and broadcasting the determined main voting value to other consensus nodes;
determining a final voting value of the current round based on the main voting values of the current round broadcast by other consensus nodes, and broadcasting the determined final voting value to other consensus nodes by using a reliable broadcast RBC protocol;
and determining the consensus condition of the proposal to be consensus based on the received final vote value of the current round of reliable broadcast RBC protocol broadcast by other consensus nodes.
2. The method of claim 1, wherein said reliable broadcast RBC protocol is an unconditionally safe reliable broadcast RBC protocol.
3. The method of claim 1, wherein determining the round of master vote values based on the round of pre-vote values broadcast by the other consensus nodes comprises:
under the condition that 2f +1 current-round pre-voting values broadcasted by other consensus nodes are received and the 2f +1 current-round pre-voting values are the same, adding voting values corresponding to the 2f +1 current-round pre-voting values into a current-round voting set;
the value that was first added to the current round of voting sets is determined to be the current round of master voting value.
4. The method of claim 3, wherein determining the current round final vote value based on the current round main vote values broadcast by the other consensus nodes comprises:
carrying out validity verification on the received main voting value in the current round based on the voting set in the current round;
and under the condition that N-f legal main voting values are received, determining a final voting value based on the N-f legal main voting values.
5. The method of claim 4, wherein determining a final vote value based on the N-f legitimate rounds of master vote values comprises:
if the N-f main voting values in the legal local round are the same, determining the voting values corresponding to the N-f main voting values in the legal local round as final voting values;
and if the main voting values of the N-f legal current rounds are not identical, determining that the final voting value is a predefined value different from the first voting value and the second voting value.
6. The method according to claim 5, wherein the determining the consensus situation of the proposal to be consensus based on the received final vote value of the current round broadcasted by the other consensus nodes using reliable broadcast RBC protocol comprises:
carrying out validity verification on the received final voting value of the current round based on the voting set of the current round;
under the condition that N-f legal local-round final voting values are received, if the N-f local-round final voting values are the same and are the first voting value or the second voting value, determining the voting value corresponding to the N-f local-round final voting values as the consensus result of the proposal to be consensus, and determining the voting value corresponding to the N-f local-round final voting values as the pre-voting value for the next consensus.
7. The method of claim 6, further comprising:
if the final voting values of the N-f legal home rounds are not completely the same, and f +1 home rounds with the same final voting value are the first voting value or the second voting value, determining the voting value corresponding to the f +1 home rounds with the same final voting value as the pre-voting value of the next round;
if f +1 identical voting values do not exist in the final voting values of the N-f legal local rounds, a local money throwing value is randomly determined, the local money throwing value is a first voting value or a second voting value, and the local money throwing value is determined as a next round of consensus pre-voting value.
8. A binary consensus device based on reliable broadcast is characterized by being applied to any consensus node in a distributed system, wherein the distributed system at least comprises N consensus nodes, N is greater than or equal to 3f +1, f is an integer greater than 0, and the device comprises:
the processing module is used for determining an initial vote value corresponding to the proposal to be consensus for any consensus node; the proposal to be consensus provides data for the consensus node and expects other consensus nodes to perform consensus; the voting value is used for expressing the consensus opinion to be treated by each consensus node; the initial vote value comprises the first vote value or the second vote value; executing each round of consensus step in a circulating way until a preset stop condition is reached;
wherein in each round of consensus:
the communication module broadcasts the current round of pre-voting values to other consensus nodes; the processing module is used for modifying the local pre-voting value into the voting value corresponding to the f +1 local pre-voting values under the condition that f +1 local pre-voting values broadcasted by other consensus nodes are received, are the same and are different from the pre-voting value broadcasted by the local node, and rebroadcasting the modified pre-voting values; the processing module is further configured to determine a main voting value of the current round based on the pre-voting values of the current round broadcast by other consensus nodes, and the communication module is further configured to broadcast the determined main voting value to other consensus nodes; the processing module is further configured to determine a final vote value of the current round based on the main vote values of the current round broadcast by other consensus nodes, and the communication module is further configured to broadcast the determined final vote value to other consensus nodes by using a reliable broadcast RBC protocol;
the processing module is further configured to determine a consensus result of the proposal to be consensus based on the received vote values of the current round broadcasted by the other consensus nodes.
9. A computer device comprising a memory, a processor, a communication interface and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 7 when executing the program.
10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method of any one of claims 1 to 7.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110984390.0A CN113794694B (en) | 2021-08-25 | 2021-08-25 | Binary consensus method and device based on reliable broadcast |
| PCT/CN2022/111009 WO2023024886A1 (en) | 2021-08-25 | 2022-08-09 | Reliable broadcast-based binary consensus method and apparatus, electronic device, and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110984390.0A CN113794694B (en) | 2021-08-25 | 2021-08-25 | Binary consensus method and device based on reliable broadcast |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113794694A CN113794694A (en) | 2021-12-14 |
| CN113794694B true CN113794694B (en) | 2022-08-26 |
Family
ID=79182236
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110984390.0A Active CN113794694B (en) | 2021-08-25 | 2021-08-25 | Binary consensus method and device based on reliable broadcast |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113794694B (en) |
| WO (1) | WO2023024886A1 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113783935B (en) * | 2021-08-12 | 2022-04-01 | 清华大学 | Byzantine fault-tolerant method and device |
| CN113794694B (en) * | 2021-08-25 | 2022-08-26 | 清华大学 | Binary consensus method and device based on reliable broadcast |
| CN114401271A (en) * | 2022-01-13 | 2022-04-26 | 中国人民解放军国防科技大学 | Test data tamper-proof method, block chain system and medium |
| CN114861233B (en) * | 2022-04-19 | 2023-12-19 | 湖南天河国云科技有限公司 | Fragmenting asynchronous Bayesian family fault-tolerant consensus method and device without trusted third party |
| CN116455904B (en) * | 2023-06-12 | 2023-09-05 | 湖南天河国云科技有限公司 | Block chain consensus method and system based on asynchronous network decentralization |
| CN117354318B (en) * | 2023-09-28 | 2024-04-05 | 北京航空航天大学 | Practical distributed voting consensus method, device, equipment and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108108487A (en) * | 2018-01-10 | 2018-06-01 | 杭州复杂美科技有限公司 | A kind of common recognition method of block chain |
| KR20200081533A (en) * | 2018-12-27 | 2020-07-08 | 서강대학교산학협력단 | Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110943838A (en) * | 2018-09-21 | 2020-03-31 | 上海派链信息科技有限公司 | Method, apparatus and storage medium for determining consensus of blocks in a blockchain network |
| CN110022216B (en) * | 2019-02-18 | 2022-02-01 | 西安链融科技有限公司 | Efficient asynchronous Byzantine consensus method with low communication complexity and network communication platform |
| US20210026745A1 (en) * | 2019-07-24 | 2021-01-28 | The University Of North Carolina At Charlotte | Methods, systems, and computer readable media for providing byzantine fault tolerance |
| CN111414373B (en) * | 2020-03-18 | 2023-09-19 | 深圳市迅雷网络技术有限公司 | Consensus method and consensus system |
| CN112286731A (en) * | 2020-07-03 | 2021-01-29 | 支付宝(杭州)信息技术有限公司 | Restarting processing method of block chain consensus node, consensus node and block chain system |
| CN111522800B (en) * | 2020-07-03 | 2020-10-30 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
| CN113794694B (en) * | 2021-08-25 | 2022-08-26 | 清华大学 | Binary consensus method and device based on reliable broadcast |
-
2021
- 2021-08-25 CN CN202110984390.0A patent/CN113794694B/en active Active
-
2022
- 2022-08-09 WO PCT/CN2022/111009 patent/WO2023024886A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108108487A (en) * | 2018-01-10 | 2018-06-01 | 杭州复杂美科技有限公司 | A kind of common recognition method of block chain |
| KR20200081533A (en) * | 2018-12-27 | 2020-07-08 | 서강대학교산학협력단 | Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment |
Non-Patent Citations (2)
| Title |
|---|
| A_Survey_of_Distributed_Consensus_Protocols_for_Blockchain_Networks;Yang Xiao等;《IEEE》;20200128;全文 * |
| 异步环境下的拜占庭共识算法研究;翁良;《中国优秀硕士学位论文全文数据库》;20200215;第1-5章 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023024886A1 (en) | 2023-03-02 |
| CN113794694A (en) | 2021-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113794694B (en) | Binary consensus method and device based on reliable broadcast | |
| CN111490878B (en) | Key generation method, device, equipment and medium | |
| US11830001B2 (en) | Blockchain consensus method, accounting node and node | |
| CN113783935B (en) | Byzantine fault-tolerant method and device | |
| CN113810465B (en) | Asynchronous binary consensus method and device | |
| CN113783708B (en) | Reliable broadcast-based re-voting binary consensus method and device | |
| EP4053711A1 (en) | Consensus method for blockchain, and consensus node, electronic device and storage medium | |
| CN111639932B (en) | Offline resource transfer method and device based on block chain | |
| CN110177124B (en) | Identity authentication method based on block chain and related equipment | |
| CN110400217B (en) | Rule change processing method and device for intelligent contract | |
| CN108737105B (en) | Method and device for retrieving private key, private key equipment and medium | |
| CN110874650A (en) | Alliance learning method, device and system fusing public domain data and private data | |
| CN113794576B (en) | Re-voting binary consensus method and device | |
| CN112134883A (en) | Method and device for quickly authenticating trust relationship between nodes based on trusted computing and related products | |
| CN110928952A (en) | Data synchronization method and device based on block chain | |
| CN111259428A (en) | Data processing method and device based on block chain, node equipment and storage medium | |
| CN110874647A (en) | Private data evaluation and league learning method, device and system in league learning | |
| CN113794566B (en) | Re-voting binary consensus method, device and storage medium | |
| CN113783946B (en) | Re-voted binary consensus method and device based on threshold signature | |
| US9698983B2 (en) | Method and apparatus for disabling algorithms in a device | |
| CN111884808B (en) | Method and device for preventing transaction cross-chain replay and electronic equipment | |
| CN117134911B (en) | Secret sharing method, secret segmentation terminal, secret recovery terminal, system and medium | |
| CN112788121B (en) | Method and system for calculating global reputation value in internet node and related product | |
| CN113726764B (en) | Private data transmission method and device | |
| CN109615382A (en) | Transfer account method, device and equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |