CN113794566A - Re-voting binary consensus method and device - Google Patents
Re-voting binary consensus method and device Download PDFInfo
- Publication number
- CN113794566A CN113794566A CN202110983026.2A CN202110983026A CN113794566A CN 113794566 A CN113794566 A CN 113794566A CN 202110983026 A CN202110983026 A CN 202110983026A CN 113794566 A CN113794566 A CN 113794566A
- Authority
- CN
- China
- Prior art keywords
- consensus
- value
- voting
- round
- priority
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
Abstract
The embodiment of the application provides a binary consensus method and a binary consensus device capable of voting again, which are applied to any one of N consensus nodes, and the method comprises the following steps: determining an initial vote value for any one to-be-consensus proposal; under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again; broadcasting first-round three-class consensus information carrying initial voting values; and agreeing on the priority voting value based on the first three kinds of agreement information broadcasted by other agreement nodes. By adopting the consensus method provided by the embodiment of the application, each consensus node broadcasts the vote value in the consensus head turn, wherein the vote value comprises the priority vote value, so that each consensus node can rapidly achieve consensus on the priority vote value in the consensus head turn with high probability, and the consensus efficiency of each consensus node in a distributed system 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 capable of re-voting.
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 a binary consensus device capable of voting again, which are used for solving the problem of low binary consensus efficiency in the prior art.
According to a first aspect of the embodiments of the present application, a binary consensus method is provided, where the binary consensus method 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:
determining an initial vote value for any one to-be-consensus proposal; the voting value comprises a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values;
under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again;
broadcasting first-round three-class consensus information carrying the voting values;
and agreeing on the priority voting value based on the first three kinds of agreement information broadcasted by other agreement nodes.
According to a second aspect of the embodiments of the present application, there is provided a two-element consensus device capable of re-voting, 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:
a processing module for determining an initial vote value for any proposal to be consensus; the voting value comprises a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values;
under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again;
the communication module broadcasts the first-round three-class consensus message carrying the voting value;
the processing module is further configured to agree on the priority vote value based on the first three types of consensus messages broadcast by other consensus nodes.
By adopting the consensus method provided by the embodiment of the application, each consensus node broadcasts the vote value for three times in the consensus head turn, wherein the vote value comprises the priority vote value, so that each consensus node can quickly achieve consensus on the priority vote value in the consensus head turn, the consensus efficiency of each consensus node in the distributed system is improved, and the processing capacity of the distributed system is further 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. 1a is a schematic diagram of a consensus node maintaining respective RABA instances in an embodiment of the present disclosure;
fig. 1b is a schematic diagram of another consensus node maintaining respective RABA instances according to an embodiment of the present disclosure;
FIG. 2 is a schematic flow chart illustrating a re-voted binary consensus method according to an embodiment of the present disclosure;
fig. 3 is a flowchart illustrating a method for broadcasting a consensus message according to an embodiment of the present disclosure;
FIG. 4 is a schematic flow chart diagram illustrating another re-voted binary consensus method according to an embodiment of the present disclosure;
fig. 5 is a schematic diagram illustrating communication among the consensus nodes in each round of consensus process according to an embodiment of the present disclosure;
FIG. 6 is a schematic structural diagram of a re-voted binary consensus device according to an embodiment of the present disclosure;
fig. 7 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 a main component of a byzantine fault-tolerant protocol (BFT), and currently known asynchronous byzantine consensus protocols all depend on the binary consensus directly or indirectly, which can enable distributed systems such as a block chain 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.
In the binary consensus, binary refers to 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 binary consensus as an example for applying to a block chain network, the data of each node in the block chain network needs to be kept consistent, if the data of each node in the block chain is ensured to be consistent by using a binary consensus method, each node stores the data when the consensus achieved by each node for a certain batch of transactions is 1, and each node does not store the data when the consensus achieved by each node for a certain batch of transactions is 0, so that the consistency of the data stored by each node is ensured. It can be understood that, if the execution efficiency of the binary consensus is higher, each node can quickly agree on a certain value in the binary, and the performance of the distributed system is better, so how to improve the efficiency of the binary consensus is an important research direction in the industry at present.
In view of the above problems, an embodiment of the present application provides a binary consensus method capable of re-voting, which is applied to any one consensus node in a distributed system, where the node broadcasts a first-round consensus message including a priority vote value, and agrees on the priority vote value in the first round based on the received first-round consensus messages sent by other consensus nodes, so as to improve the consensus efficiency of binary consensus.
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.
In order to make the present solution more clear to those skilled in the art, some terms appearing in the present specification are explained below:
in this specification, a proposal to be consensus-identified may be understood as data sent by any consensus node, and it is desirable 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 two values, namely, the respective consensus nodes may have two consensus opinions together on the proposal to be consensus-identified, and the two values may be represented by 1 and 0 respectively in one embodiment, and may be represented by other forms and symbols in other embodiments.
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. 1a, is any one of the distributed systemsFor convenience of description, any one of the two consensus nodes is referred to as a target node, and the target node in the distributed system determines, for each consensus node (including itself), a consensus result of a candidate consensus proposal proposed by the node by using the re-voted binary consensus method proposed in the description; as shown in the figure, RABA1-RABANSchematic diagrams respectively representing a two-element consensus method RABA for re-voting on N proposals to be consensus, RABA1Schematic representation of the proposal for consensus to be proposed for the target node for consensus node 1, RABA, using the re-voted binary consensus method proposed in this specification2The proposal for the target node to be consensus on the consensus node 2 is processed by the two-element consensus method for voting proposed in this specification, 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), and finally the binary consensus method proposed based on the present description also obtains a consensus result (0 or 1) for the to-be-consensus proposal.
As shown in fig. 2, based on the above description, the binary consensus method capable of re-voting proposed in this specification is applied to any consensus node in a distributed system, where the distributed system at least includes N consensus nodes, where a consensus node refers to a node participating in a consensus process, and it can be understood that there are other nodes that do not participate in the consensus process in the distributed system, and these nodes only receive and store the consensus result of the consensus node 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, where 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.
It can be understood that in the distributed system proposed in this specification, each node has no primary and secondary points, and each consensus node asynchronously executes the following method, when a target node obtains a consensus result for a to-be-consensus proposal proposed by any one 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:
s201, determining an initial voting value aiming at any proposal to be identified; the voting value comprises a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values;
s202, under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again;
in this specification, the voting value includes a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values; in this specification, it is proposed to set one of the voting values as a priority voting value, that is, it is desirable that each consensus node is biased toward the priority voting value to achieve consensus, and in a specific example, 0 and 1 may be used to respectively represent the priority voting value and other voting values, where the priority voting value may be 1 or 0, and hereinafter, the priority voting value is 1, and the other voting values are 0 for example.
As shown in fig. 1a and the description of fig. 1a, the target node determines the consensus result for each candidate consensus proposal of the consensus node, which is the consensus process to be performed by the target node for each candidate consensus proposal as described in fig. 2.
In S201, the initial vote value may be determined according to different data in different application scenarios. In the blockchain network, each consensus node may broadcast a to-be-consensus proposal based on a reliable broadcast RBC, and may determine an initial vote value for the to-be-consensus proposal based on a condition of receiving the to-be-consensus proposal, and in the blockchain network, the target node may randomly acquire a preset number of transactions from a local transaction pool, or preferentially acquire a preset number of transactions stored earlier according to a sequence of transaction storage. It can be understood that each consensus node may maintain its own transaction pool locally, since each consensus node will receive the transaction requested by the client. After the target node acquires the transaction, the acquired transaction can be packaged into the current proposal to be identified. After the target node obtains the local to-be-identified proposal, the target node can broadcast the local to-be-identified proposal to other common identification nodes based on the reliable broadcast RBC protocol, and can receive the to-be-identified proposal broadcast by other common identification nodes based on the reliable broadcast RBC protocol. The details of the reliable broadcast RBC protocol can be found in the related art, and will not be described in detail in this specification.
Each consensus node can send out local to-be-consensus suggestions at the same time, so that the target node may receive the to-be-consensus suggestions sent by different consensus nodes in sequence.
Specifically, the target node may determine, when receiving a to-be-consensus proposal broadcast by any consensus node through a reliable broadcast RBC protocol, if a consensus process has not been started for the to-be-consensus proposal, that is, S201 to S204, an initial vote value of the to-be-consensus proposal is determined to be a priority vote value 1;
under the condition that the proposals to be consensus broadcasted by the N-f consensus nodes are received, determining the initial vote value of the proposals to be consensus which do not start to execute the consensus process as other vote values 0;
in addition, when the target node receives the to-be-consensus proposal broadcast by any consensus node through the reliable broadcast RBC protocol, if the consensus process is started to be executed for the to-be-consensus proposal and the consensus result of the to-be-consensus proposal is not obtained yet, the initial vote value of the to-be-consensus proposal is determined to be the priority vote value 1 again.
In this embodiment, in the case of receiving the to-be-consensus proposals broadcasted by the N-f consensus nodes, the initial vote value of the to-be-consensus proposal not yet starting to perform the consensus process is determined as the other vote value 0, and the reliable broadcast RBC protocol can ensure that the target node receives only one time when receiving any one of the to-be-consensus proposals, rather than receiving the same to-be-consensus proposal multiple times, therefore, after receiving any one of the to-be-consensus proposals, if the consensus process has already started for the to-be-consensus proposal, it is stated that the execution is started with the other vote value 0 as the initial vote value, and further, the initial vote value can be modified from the other vote value 0 to the prior vote value 1. That is, in the blockchain network scenario, the preset condition may be configured as: if the proposal to be agreed upon is received, and the consensus result of the proposal to be agreed upon is not obtained yet.
Taking N as 7 and f as 2 as an example, after receiving a to-be-consensus proposal broadcast by any consensus node, the target node determines whether to start performing a consensus process on the to-be-consensus proposal, if not, determines an initial vote value of the to-be-consensus proposal as a priority vote value 1, and starts performing S203-S204 to obtain a consensus result on the to-be-consensus proposal.
In addition, when it is determined that N-f, that is, 7-2, to the to-be-consensus suggestions broadcasted by 5 consensus nodes are received, that is, the consensus process has started to be performed for the 5 to-be-consensus suggestions respectively with the priority vote value 1 as an input, the initial vote value of the remaining 2 to-be-consensus suggestions for which the consensus process has not started to be performed may be determined as the other vote value 0, and the consensus process may be started to be performed for the remaining 2 to-be-consensus suggestions.
Meanwhile, after receiving the to-be-consensus proposal broadcast by any consensus node, if the consensus process is started for the to-be-consensus proposal, the initial vote value of the to-be-consensus proposal is other vote values 0, and the consensus result of the to-be-consensus proposal is not obtained yet, the target node determines the initial vote value of the to-be-consensus proposal as the priority vote value again.
In the event that it is determined that there is an initial vote value for any one of the to-be-consensus offers, the consensus process is performed for that to-be-consensus offer.
As illustrated in FIG. 1b, a blockchain networkThere are 7 consensus nodes in total, each consensus node needs to respectively achieve consensus on the to-be-consensus proposals sent out by the 7 consensus nodes, as shown in the figure, 7 pairs of RBC + RABA examples need to be maintained, where RABA is a re-voted binary consensus method proposed in this specification, where N is 7, f is 2, and the target node starts to respectively execute a re-voted binary consensus algorithm RABA (reprocessable asynchronous aggregation) on the to-be-consensus proposals of the nodes 0 to 4 after receiving the 5 to-be-consensus proposals of the nodes 0 to 4 through a reliable broadcast RBC protocol, that is, RABA0-RABA4Are set to 1 (priority vote value) and start execution, and RABAs corresponding to nodes 5 and 6 are directly input5And RABA6Is set to 0 (other vote value) and starts execution, i.e. in case of receiving the last one of the N-f consensus nodes' consensus proposals to be agreed upon, it starts triggering the start of execution of the remaining f consensus proposals that have not started execution of the RABA, as shown in the figure, starting RABA execution at node 3 with 1 as input3Then RABA is added5And RABA6Are all set to 0, triggers the start of the execution of the RABA5And RABA6. In addition, RABA for node 5 and node 65And RABA6After the input of (1) is set to 0, and no RABA has been obtained yet5And RABA6When the result is output, if the co-recognition proposals to be received by the node 5 and the node 6 are received again, the RABA can be used5And RABA6Is changed to 1, again triggers execution of the RABA5And RABA6To obtain RABA5And RABA6And outputting the result. By adopting the mode, the binary consensus process of each consensus proposal to be treated is basically processed and generated in parallel, and the consensus efficiency is further improved.
It will be appreciated that the above approach is merely an approach to determining an initial vote value in a blockchain network, and in other application scenarios, the initial vote value for a proposal to be consensus may also be determined from different data.
In the above S201, in the case that the target node determines the initial vote value, the target node may perform S203, regardless of whether the initial vote value is the priority vote value or another vote value, that is, broadcast the initial vote value, and receive the initial vote value broadcast by another consensus node for the to-be-consensus proposal.
In addition, in order to enable each consensus node to quickly achieve consensus on the priority vote value in the initial consensus process, the present specification proposes that the target node may determine the initial vote value as the priority vote value again if it is determined that the predetermined condition is satisfied in the case that the determined initial vote value is another vote value, and then perform S203 again. And under the condition that the preset conditions are not met, the target node is not allowed to modify the initial voting value, and different preset conditions can be flexibly configured in different application scenes of the distributed system. It can be understood that, the above description only takes the application scenario of the blockchain network as an example, in other application scenarios, different preset conditions may be configured according to different scenario requirements, in this step, the target node is allowed to vote again, that is, the initial vote value is determined twice for the same to-be-consensus proposed, and the target node is allowed to modify the initial vote value to the priority vote value when the initial vote value of a to-be-consensus proposed is other vote values, so as to enable each consensus node to quickly agree on the priority vote value.
S203, broadcasting three types of consensus information carrying the voting values;
and S204, agreeing on the priority voting value based on the three types of consensus messages broadcast by other consensus nodes.
In S203, the target node may specifically execute the steps illustrated in fig. 3:
s301, carrying the initial voting value in the first-round first consensus message for broadcasting; receiving first round first consensus information broadcast by other consensus nodes;
the target node may determine the initial vote value according to the above method, and the target node may add the locally determined initial vote value to the first consensus message, and transmit the first consensus message to other consensus nodes in the distributed system through the authentication channel, and certainly, when there is no authentication channel, in order to ensure the security of data transmission, the security of transmission of the consensus message may also be ensured through cryptographic tools such as a digital signature or a public key technology facility, which is not limited in this specification.
In one embodiment, the first common identification message may be a bvalrThe message in the form of a broadcast, e.g. bval, by the target noder(estr) Message of estrFor the voting value, the voting value estrIs a binary number (0 or 1), r is a consensus round, the first round is the 0 th round, and the consensus round is increased by 1 step from 0. It is understood that all correct nodes in the distributed system are performing the steps performed by the target node, i.e. other consensus nodes will also broadcast the first consensus message including the vote value; at this time, the target node receives the first consensus information sent by other consensus nodes, that is, each consensus node carries the voting opinions corresponding to a to-be-consensus suggestion by itself through the consensus information.
In one embodiment, if the target node receives f +1 first consensus messages, i.e. the first consensus messages exceeding the number of malicious nodes, in the current consensus round, if the vote values in the f +1 first consensus messages are the same and inconsistent with the vote value broadcasted locally, the target node modifies the local vote value of the round to be the same as the vote value in the f +1 first consensus messages, and broadcasts the first consensus message again. For example, if the target node receives f +1 bvalsr(b) Message, and b the first broadcast voting value est with the current round of the target noderNot equal, the target node will broadcast
Wherein the content of the first and second substances,
this step is intended to allow the local node to correct the local vote value.
S302, re-determining the initial voting value based on the initial voting value and the initial first consensus information broadcasted by other consensus nodes, and carrying the re-determined initial voting value in the initial second consensus information for broadcasting;
each consensus node only sends the second consensus message once in each round, and the specific way of determining the information carried in the second consensus message may be as follows:
in one embodiment, the target node may determine the initial vote value as the first-round vote value, and add the determined first-round vote value to the first-round second consensus message for broadcasting.
For example, the target node broadcasts a bval0(est0) Message of est0Is 1 (priority vote value), 1 can be directly stored in bin _ values0(first round first set, r ═ 0) and broadcast aux0(1). Wherein auxrIn a second consensus message format.
In addition, under the condition that the local initial vote value of the target node is not the priority vote value, and the target node receives 2f +1 first consensus messages, the first-round vote value can be determined again according to the received first consensus messages, specifically, if the vote values in the 2f +1 first consensus messages are the same, the target node adds the vote value to the first set of the first round. For example, if the target node receives 2f +1 bval0(b) Message, b ∈ {0,1 }. The target node adds b to the first set bin values of the first round0In (1). In this step, in the case that 2f +1 identical vote values are received, it means that most of the node vote values in the system are identical.
And after adding the value in the first round first set, the target node determines the voting value which is firstly added into the first round first set as the voting value in the first round second consensus message, namely, the newly determined first round voting value, and adds the newly determined first round voting value into the first round second consensus message for broadcasting.
And S303, determining a value in a second set based on the redetermined first-round voting value and the first-round second consensus message broadcasted by other consensus nodes, and carrying the second set in a first-round third consensus message for broadcasting.
After the target node sends the first round second consensus message, it may first determine whether a vote value carried in the locally sent first round second consensus message is a priority vote value, and if so, add the priority vote value to the second set of the current round. For example, the first round second consensus message of the target node is aux0(1) Then 1 (preferential vote value) can be directly added to the first round second set vals, and the first round second set vals is carried in the third consensus message conf0() In that conf is sent via a third consensus message0(1)。
In addition, if the vote value carried in the locally transmitted first-round second consensus information is not the priority vote value but other vote values, all vote values in the received second consensus information are determined as the values in the first-round second set under the condition that N-f legal second consensus information are received.
The legal second consensus message is that the vote value in the received first round second consensus message is stored in the local first round set, if the vote value is not stored in the local first round first set, the message is not received temporarily, but the message is cached first, and the processing is performed until the vote value is stored in the local first round first set.
The vote value carried in the N-f legal second consensus messages may include both the priority vote value 1 and other vote values 0, then both 1 and 0 are added to the first round second set vals, and the first round second set is carried in the third consensus message, and the third consensus message is broadcast.
In the above-described process of S203, that is, the process of broadcasting the vote value in the first round, in the above-described manner, after the target node locally sends the priority vote value through the first type of consensus message, the priority vote value may be directly broadcast through the second type of consensus message, and after the priority vote value is locally sent through the second type of consensus message, the priority vote value may be directly broadcast through the third type of consensus message without referring to the opinions of other consensus nodes.
The following describes the procedure of agreeing on the priority vote value based on the first three types of consensus messages broadcast by other consensus nodes in S204:
specifically, the first-round public money throwing value may be set as a priority voting value when N-f legal third consensus messages are received, and if the voting values carried in the received third consensus messages are the same and are the first-round public money throwing values, the consensus result is determined to be the priority voting value. The term "legal" means that the vote value in the received first-round third consensus message is stored in the local first-round set, and if the vote value does not exist, the vote value is not received for the moment.
For example, the received N-f legal third consensus messages are conf0(1) That is, only one value is carried in the second set and is the priority voting value, the round of public coin throwing value is defaulted to be the priority voting value 1, that is, the voting values carried in the received third consensus message are all the round of public coin throwing values, and then the consensus result is determined to be the priority voting value 1.
In addition, if the values in the second set carried by the N-f legal third consensus messages are not completely the same, or the values in the second set carried by the N-f legal third consensus messages are the same but not the preferred vote value, the vote value carried by the second round of first consensus messages is determined to be the preferred vote value, and the second round of consensus process is started.
Therefore, by adopting the consensus method, the prior voting values of all the consensus nodes can be quickly identified in the first round, namely, the consensus can be achieved at a high probability only through one round of consensus, and the consensus efficiency is greatly improved.
The consensus method proposed in this specification is executed in rounds, where each round of consensus includes several steps, where the above-mentioned S201-S204 are steps executed by the first round of consensus, and the steps executed by other rounds of consensus are described below:
except for the first round, the consensus of the other rounds is achieved by adopting the method shown in fig. 4:
under the condition that the first round does not agree on the prior voting value, the loop execution of S401-S402 can be started until a preset stop condition is reached, wherein the preset stop condition can be that a consensus result is obtained, and the common coin throwing value of the current round is determined to be 1; or receiving a stop instruction, etc. In addition, any node can obtain a consensus result only once, and after the consensus result is obtained, the node can participate in the next round of consensus but can not obtain the consensus result again.
S401, broadcasting the three types of consensus information of the current round, wherein the three types of consensus information of the current round carries the voting value of the current round;
s402, determining the consensus situation of the proposal to be consensus based on the received three types of consensus messages broadcasted by other consensus nodes in the current round.
Wherein, in S401, specifically, may be:
s401a, carrying the voting value of the round in the first consensus message for broadcasting; receiving a first consensus message broadcast by other consensus nodes;
s401b, re-determining the voting value of the current round based on the first consensus information broadcast by other consensus nodes, and carrying the re-determined voting value of the current round in the second consensus information for broadcasting;
s401c, determining the value in the second set of the current round based on the second consensus messages of the current round broadcast by other consensus nodes, and broadcasting the second set of the current round carried in the third consensus messages of the current round.
The content of S401a can refer to S301 above, and is not described in detail here, except that the vote value broadcast by the first consensus message in S301 is the initial vote value, and the vote value broadcast by the first consensus message in S401a is the vote value obtained based on the previous round of consensus results.
S401b may specifically be:
the target node may re-determine the vote value of the current round according to the received first consensus message when receiving 2f +1 first consensus messages of the current round, specifically, if the vote values in the 2f +1 first consensus messages of the current round are the same, the target node adds the vote value to the first set. For example, if the target node receives 2f +1 bvalr(b) Message, b ∈ {0,1 }. The target node adds b to the first set bin values of the current roundrIn (1). In this step, inAnd under the condition that 2f +1 identical voting values are received, storing the voting values into a first set of the current round, determining the voting value which is added into the first set of the current round firstly as the voting value in the second consensus message of the current round after the target node adds the value into the first set of the current round, namely, the newly determined voting value of the current round, and adding the newly determined voting value of the current round into the second consensus message of the current round for broadcasting.
S401c may specifically be: and under the condition that N-f legal second consensus messages are received, determining the voting value in the received second consensus messages as the value in the second set.
And the vote value carried in the N-f legal second consensus messages can comprise a priority vote value 1 and other vote values 0, and then 1 and 0 are added into the second set vals of the current round, the second set of the current round is carried in the third consensus message of the current round, and the third consensus message of the current round is broadcasted.
The above-described process of S401, that is, the process of broadcasting the vote value in the other rounds except the first round, is described as follows:
under the condition of receiving N-f legal third consensus messages, determining the common coin-throwing value of the current round, wherein the common coin-throwing value only has two values of 0 or 1, each consensus node can negotiate the same common coin-throwing value in a certain round, the coin-throwing values of other rounds except the first round are random, the method for obtaining the common coin-throwing value can be obtained by adopting a threshold signature algorithm and the like, the specific content can refer to related technologies, and the method is not limited herein. After the current round of common coin throwing values are determined, if the voting values carried in the received third consensus messages are the same and are the common coin throwing values, determining that the consensus result is the voting value. Otherwise, setting the voting value carried in the first consensus information of the next round as the common coin throwing value of the current round, and starting to execute the next round of consensus.
For example, the received N-f third consensus messages confrOnly one value of the voting value carried in the voting table is a priority voting value 1 or other voting valuesAnd 0, if the coin cast in the round is 1 or 0 and the voting value carried in the third consensus information is the same, determining that the consensus result is the voting value, and if not, starting to execute the next round of consensus.
It is understood that the above-mentioned manner is a method performed by any correct node in the consensus nodes, and other correct consensus nodes also perform the above-mentioned method asynchronously, and in the above-mentioned manner, the priority vote value is set, and in the first round, each consensus node has a large probability to achieve consensus on the priority vote value, and in each round of consensus process, the consensus node only needs to perform 3-4 steps (the step of broadcasting the third consensus message and determining the consensus result), and the probability of ending each round is 1/2 from the first round, so that after k rounds of consensus, the probability of each node achieving consensus is 1- (1/2)kExperiments prove that the number of rounds of consensus completed by each consensus node is two on average, so that each consensus node only needs to execute 6-8 steps when being in consensus each time. In conclusion, by adopting the method, each consensus node in the distributed system under the asynchronous environment can quickly reach the consensus state with respect to a certain value, and the consensus efficiency of the distributed system under the asynchronous environment is greatly improved. Meanwhile, the consensus method can ensure that the consensus nodes in the distributed system meet the following properties, namely the following technical effects: effectiveness: under the condition that the voting values broadcast by all correct nodes are v and other voting values are not broadcast again, the consensus results of all correct nodes are the voting values v; and (5) consistent termination: under the condition that the voting values broadcast by all correct nodes are the same value v and other voting values are not broadcast again, all correct nodes can terminate consensus operation, namely consensus is achieved; consensus property: if any correct node determines that a certain voting value v is a consensus result, other correct nodes terminating the consensus operation also determine that the voting value v is the consensus result; biased effectiveness: if f +1 correct nodes broadcast the voting value v, the correct nodes can determine that the voting value v is a consensus result when the consensus is terminated; terminating with bias: if Q is the set of correct nodes, where Q1 is the set of correct nodes that broadcast a vote value of 1 without rebroadcasting a vote value of 0, and Q2 is the set of correct nodes that broadcast a vote value of 0 and rebroadcast a vote value of 1If the correct node is set
And Q1 ═ Q2, then all correct nodes agree; integrity: the correct node agrees only once with a proposal.
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 two-element consensus voter method of the present specification is described below from the code implementation perspective:
the pseudo code is as follows:
in the above pseudo code:
if the dispose (v) is triggered, the node starts the 0 th round and calls a trigger (v) function; trigger (v) is called if reprocess (1) is triggered and the node is still in round 0. Invoke trigger (v), then the node broadcasts bval0(v) If v ═ 1 and aux0() Not sent out, then broadcast aux0(1) If conf0() If not sent, broadcast conf0(1). The common throw of the first round is set to 0. The flow of round r is described below.
Node broadcast bvalr(estr). If the node receives f +1 bvalr(v) But not the broadcast of bvar (v), the broadcast of bvarr(v) In that respect The node receives N-f uniform bvalr(v) Message, v is added to the bin _ values set.
For the first value v added to bin _ values and no aux was issued by the noder() Node broadcast auxr(v) In that respect For each collected auxr(b) The node receives this message if b has already been added to the local bin _ values, otherwise the node buffers the message and needs to wait for b to be included in bin _ values before processing.
Collecting n-f pieces of aux from nodesr() Begin processing after the message, where vals is the received auxr() A value of (1). Node broadcast confr(vals) message. For each collected confr(b) The node accepts this message if b has been added to the local bin _ values, if conf is receivedr(0,1), then both 0 and 1 must be in bin _ values, otherwise the node will buffer the message and will need to wait for the bin values to contain enough values to process.
Collecting n-f confs from nodesr() Starting processing after the message, where vals is the received confr() A value of (1). And the node starts to interactively acquire the public coin throwing with other nodes, and in the 0 th round, the node sets the public coin throwing to be 1 and processes the public coin throwing. If the node collects only one value ρ, and ρ equals the common throw, then it is decided. In other cases, the node may use the common throw as the input est for the next roundr+1。
As shown in fig. 5, it is a schematic diagram of the communication performed by each consensus node in each round of consensus process in the above two-element consensus method capable of re-voting, that is, each consensus node firstly adds a vote value to a first consensus message and broadcasts to other nodes, adopts a second consensus message to broadcast after reconfirming the vote value, adopts a third consensus message to broadcast after reconfirming the vote value, and finally determines a consensus result based on the interactive vote value.
As shown in fig. 6, corresponding to the foregoing two-element consensus method capable of re-voting, the present specification further provides a two-element consensus device capable of re-voting, 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, and the device includes:
a processing module 610 for determining an initial vote value for any one of the to-be-consensus proposals; the voting value comprises a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values;
under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again;
the communication module 620 broadcasts the first-round three-type consensus message carrying the vote value;
the processing module 610 is further configured to agree on the priority vote value based on the first three types of consensus messages broadcast by other consensus nodes.
In one embodiment, the processing module 610 is further configured to, in a case that the first round does not agree on the priority vote value, cyclically execute other rounds of consensus until a preset stop condition is reached, where in the other rounds of consensus:
a communication module 620 is called for broadcasting the third type of consensus information of the current round, wherein the third type of consensus information of the current round carries the voting value of the current round;
the processing module 610 is configured to determine a consensus situation of the to-be-consensus proposed based on the received current three types of consensus messages broadcast by other consensus nodes.
In an embodiment, the communication module 620 is specifically configured to carry the initial vote value in the first common identification message for broadcasting; receiving first round first consensus information broadcast by other consensus nodes;
the processing module 610 is specifically configured to re-determine the initial voting value based on the initial voting value and the initial first consensus message broadcast by the other consensus nodes;
the communication module 620 is specifically configured to carry the re-determined first-round vote value in the first-round second consensus message for broadcasting;
the processing module 610 is specifically configured to determine values in the second set based on the re-determined first-round voting values and the first-round second consensus messages broadcast by other consensus nodes;
the communication module 620 is specifically configured to carry the second set in the first round third consensus message for broadcasting.
In an embodiment, the processing module 610 is specifically configured to, in a case that the initial vote value is a priority vote value, re-determine the priority vote value as a first-round vote value.
In an embodiment, the processing module 610 is further configured to, when the initial vote value is not a priority vote value and 2f +1 first consensus messages broadcasted by other consensus nodes are received, add the vote value to the first set of first consensus messages if the vote values carried in the 2f +1 first consensus messages are the same, and determine the vote value added first in the first set of first consensus messages as the first vote value.
In an embodiment, the processing module 610 is specifically configured to determine that the first round vote value is a first set if the predetermined first round vote value is a second set;
and if the re-determined first round voting value is not the priority voting value, determining the voting value in the received second consensus message as the value in the first round second set under the condition that N-f legal second consensus messages are received.
In an embodiment, the processing module 610 is specifically configured to set an initial round public money throwing value as a priority voting value when N-f legal third consensus messages are received, and determine that a consensus result is the priority voting value if the voting values carried in the received third consensus messages are all the same and are the initial round public money throwing value; otherwise, setting the voting value carried in the first consensus information of the next round as the priority voting value.
In an embodiment, the communication module 620 is specifically configured to carry the vote value of the current round in the first consensus message for broadcasting; receiving a first consensus message broadcast by other consensus nodes;
the processing module 610 is specifically configured to re-determine the vote value of the current round based on the first consensus message broadcast by the other consensus nodes, and call the communication module 620 to carry the re-determined vote value of the current round in the second consensus message for broadcast;
the processing module 610 is further configured to determine values in the second set of the current round based on other consensus nodes broadcasting the second consensus message of the current round; and calling the communication module 620 to carry the second set of the current round in the third consensus message of the current round for broadcasting.
In an embodiment, the processing module 610 is specifically configured to, when 2f +1 local round first consensus messages broadcasted by other consensus nodes are received, add the vote value to the local round to the first set if the vote values carried in the 2f +1 local round first consensus messages are the same, and determine the vote value added to the local round first set first again as the local round vote value.
In an embodiment, the processing module 610 is specifically configured to, in a case that N-f legal second consensus messages are received, determine a vote value in the received second consensus message as a value in the second set.
In an embodiment, the processing module 610 determines a current round of common coin throwing values when receiving N-f legal third consensus messages, and determines that the consensus result is the vote value if the vote values carried in the received third consensus messages are the same and are the common coin throwing values; otherwise, setting the voting value carried in the first consensus information of the next round as the common coin throwing value of the current round, and starting to execute the next round of consensus.
The implementation processes of the functions and actions of the components 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 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. 2.
Fig. 7 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the 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 in a device (not shown) or may be external to the device to provide a corresponding function. 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. 2.
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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that 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 achieve 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 (15)
1. A binary consensus method capable of re-voting is 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, and f is an integer greater than 0, and the method comprises the following steps:
determining an initial vote value for any one to-be-consensus proposal; the voting value comprises a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values;
under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again;
broadcasting first-round three-class consensus information carrying the voting values;
and agreeing on the priority voting value based on the first three kinds of agreement information broadcasted by other agreement nodes.
2. The method of claim 1, further comprising:
in the case that the first round does not agree on the priority vote value, circularly executing the following other rounds of agreement steps until reaching a preset stop condition, wherein the other rounds of agreement steps comprise:
broadcasting the three types of consensus information of the current round, wherein the three types of consensus information of the current round carries the voting value of the current round;
and determining the consensus situation of the to-be-consensus proposal based on the received current three types of consensus messages broadcasted by other consensus nodes.
3. The method of claim 1, wherein broadcasting the first three types of consensus messages carrying the vote value comprises:
carrying the initial voting value in the first consensus message of the first round for broadcasting;
receiving first round first consensus information broadcast by other consensus nodes;
re-determining the initial voting value based on the initial voting value and the initial first consensus information broadcasted by other consensus nodes, and carrying the re-determined initial voting value in the initial second consensus information for broadcasting;
and determining values in a second set based on the re-determined first-round voting values and the first-round second consensus messages broadcast by other consensus nodes, and carrying the second set in a first-round third consensus message for broadcasting.
4. The method of claim 3, wherein the re-determining the first-round vote value based on the initial vote value and the first consensus message broadcast by the other consensus nodes comprises:
and in the case that the initial voting value is a priority voting value, the priority voting value is determined as a first-round voting value again.
5. The method of claim 4, further comprising:
and adding the voting value to a first-round first set and re-determining the voting value added in the first-round first set as the first-round voting value if the voting values carried in the 2f +1 first consensus messages are the same under the condition that the initial voting value is not the priority voting value and 2f +1 first consensus messages broadcasted by other consensus nodes are received.
6. The method of claim 5, wherein determining values in the second set based on the re-determined first-round vote values and first-round second consensus messages broadcast by other consensus nodes comprises:
if the re-determined first round voting value is a priority voting value, determining the priority voting value as a value in a second set;
and if the re-determined first round voting value is not the priority voting value, determining all voting values in the received second consensus message as values in the first round second set under the condition that N-f legal second consensus messages are received.
7. The method of claim 6, wherein the agreeing on the priority vote value based on first three types of consensus messages broadcast by other consensus nodes comprises:
and under the condition of receiving N-f legal third consensus messages, setting the first-round public money throwing value as a priority voting value, and if the voting values carried in the received third consensus messages are the same and are the first-round public money throwing value, determining that the consensus result is the priority voting value.
8. The method of claim 7, further comprising:
otherwise, setting the voting value carried in the first consensus information of the next round as the priority voting value.
9. The method of claim 2, wherein the broadcasting of the local round of three types of consensus messages comprises:
carrying the voting value of the current round in the first consensus information for broadcasting;
receiving a first consensus message broadcast by other consensus nodes;
re-determining the polling value of the current round based on the first consensus information broadcast by other consensus nodes, and carrying the re-determined polling value of the current round in a second consensus information for broadcasting;
and determining a value in the second set of the current round based on the broadcasting of the second consensus information of the current round by other consensus nodes, and carrying the second set of the current round in the third consensus information of the current round for broadcasting.
10. The method of claim 9, wherein the re-determining the voting value of the current round based on the first consensus message broadcast by the other consensus nodes comprises:
under the condition that 2f +1 local round first consensus messages broadcasted by other consensus nodes are received, if the voting values carried in the 2f +1 local round first consensus messages are the same, adding the voting value into the local round first set, and determining the voting value added into the local round first set firstly as the local round voting value again.
11. The method of claim 10, wherein determining values in the second set based on the other consensus nodes broadcasting the second consensus message comprises:
and under the condition that N-f legal second consensus messages are received, determining the voting value in the received second consensus messages as the value in the second set.
12. The method according to claim 11, wherein the determining the consensus situation of the candidate consensus proposal based on the received three types of consensus messages broadcasted by other consensus nodes comprises:
under the condition that N-f legal third consensus messages are received, determining the common money throwing value of the current round, and if the voting values carried in the received third consensus messages are the same and are the common money throwing values, determining the consensus result as the voting value;
otherwise, setting the voting value carried in the first consensus information of the next round as the common coin throwing value of the current round, and starting to execute the next round of consensus.
13. A binary consensus device capable of re-voting is 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:
a processing module for determining an initial vote value for any proposal to be consensus; the voting value comprises a priority voting value and other voting values, and the initial voting value is the priority voting value or other voting values;
under the condition that the initial voting value is other voting values and meets a preset condition, determining the initial voting value as a priority voting value again;
the communication module broadcasts the first-round three-class consensus message carrying the initial voting value;
the processing module is further configured to agree on the priority vote value based on the first three types of consensus messages broadcast by other consensus nodes.
14. 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 one of claims 1 to 12 when executing the program.
15. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 12.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110983026.2A CN113794566B (en) | 2021-08-25 | 2021-08-25 | Re-voting binary consensus method, device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110983026.2A CN113794566B (en) | 2021-08-25 | 2021-08-25 | Re-voting binary consensus method, device and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113794566A true CN113794566A (en) | 2021-12-14 |
| CN113794566B CN113794566B (en) | 2022-06-03 |
Family
ID=79182329
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110983026.2A Active CN113794566B (en) | 2021-08-25 | 2021-08-25 | Re-voting binary consensus method, device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113794566B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023024885A1 (en) * | 2021-08-25 | 2023-03-02 | 山东区块链研究院 | Reliable broadcast-based re-votable binary consensus method and apparatus, electronic device, and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110288479A (en) * | 2019-06-28 | 2019-09-27 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
| WO2020033048A1 (en) * | 2018-08-09 | 2020-02-13 | Hrl Laboratories, Llc | System and method for consensus ordering of broadcast messages |
| CN111414373A (en) * | 2020-03-18 | 2020-07-14 | 深圳市网心科技有限公司 | Consensus method and consensus system |
| CN112416905A (en) * | 2020-07-03 | 2021-02-26 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
-
2021
- 2021-08-25 CN CN202110983026.2A patent/CN113794566B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020033048A1 (en) * | 2018-08-09 | 2020-02-13 | Hrl Laboratories, Llc | System and method for consensus ordering of broadcast messages |
| CN110288479A (en) * | 2019-06-28 | 2019-09-27 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
| CN111414373A (en) * | 2020-03-18 | 2020-07-14 | 深圳市网心科技有限公司 | Consensus method and consensus system |
| CN112416905A (en) * | 2020-07-03 | 2021-02-26 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
Non-Patent Citations (2)
| Title |
|---|
| CHAO LIU等: "EPIC: Efficient Asynchronous BFT with Adaptive Security", 《2020 50TH ANNUAL IEEE/IFIP INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS (DSN)》 * |
| 翁良: "异步环境下的拜占庭共识算法研究", 《中国优秀硕士学位论文全文数据库（电子期刊）》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023024885A1 (en) * | 2021-08-25 | 2023-03-02 | 山东区块链研究院 | Reliable broadcast-based re-votable binary consensus method and apparatus, electronic device, and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113794566B (en) | 2022-06-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113783935B (en) | Byzantine fault-tolerant method and device | |
| CN113794694B (en) | Binary consensus method and device based on reliable broadcast | |
| KR102469267B1 (en) | Blockchain consensus method, accounting node and node | |
| CN113810465B (en) | Asynchronous binary consensus method and device | |
| CN113783708A (en) | Re-voting binary consensus method and device based on reliable broadcast | |
| CN111163130B (en) | Network service system and data transmission method thereof | |
| CN109831746B (en) | Method and device for data transmission based on Bluetooth broadcast and Bluetooth equipment | |
| CN110020854B (en) | Data evidence storage method and system based on multiple block chain networks | |
| CN113794576B (en) | Re-voting binary consensus method and device | |
| CN114070733B (en) | Consensus method, device and system based on block chain network | |
| CN111899097B (en) | Method and system for accepting blockchain certification transaction | |
| CN110007936B (en) | Data processing method and device | |
| EP4030314A1 (en) | Blockchain-based data processing method, apparatus and device, and readable storage medium | |
| CN113794566B (en) | Re-voting binary consensus method, device and storage medium | |
| CN113783946A (en) | Re-voting binary consensus method and device based on threshold signature | |
| CN112073215B (en) | Method for realizing application and service controller | |
| CN109558222B (en) | Batch business process monitoring method and device, computer and readable storage medium | |
| CN114760198B (en) | Consensus method, device and system based on block chain network | |
| CN111161072A (en) | Block chain-based random number generation method, equipment and storage medium | |
| CN110545296A (en) | Log data acquisition method, device and equipment | |
| US20170263068A1 (en) | Method for generating counting events and electronic device | |
| CN114640595A (en) | Cascading method, device, electronic equipment and storage medium | |
| CN112650763A (en) | Configuration method of product quota, related equipment and storage medium | |
| CN114900710B (en) | Multi-device synchronization method and device, electronic device and storage medium | |
| CN116055215B (en) | Communication method, system and equipment based on network security transmission protocol |
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 |