CN113794694A - Binary consensus method and device based on reliable broadcast - Google Patents

Binary consensus method and device based on reliable broadcast Download PDF

Info

Publication number
CN113794694A
CN113794694A CN202110984390.0A CN202110984390A CN113794694A CN 113794694 A CN113794694 A CN 113794694A CN 202110984390 A CN202110984390 A CN 202110984390A CN 113794694 A CN113794694 A CN 113794694A
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.)
Granted
Application number
CN202110984390.0A
Other languages
Chinese (zh)
Other versions
CN113794694B (en
Inventor
段斯斯
张海滨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shandong Blockchain Research Institute
Tsinghua University
Original Assignee
Shandong Blockchain Research Institute
Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shandong Blockchain Research Institute, Tsinghua University filed Critical Shandong Blockchain Research Institute
Priority to CN202110984390.0A priority Critical patent/CN113794694B/en
Publication of CN113794694A publication Critical patent/CN113794694A/en
Priority to PCT/CN2022/111009 priority patent/WO2023024886A1/en
Application granted granted Critical
Publication of CN113794694B publication Critical patent/CN113794694B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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

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

Binary consensus method and device based on reliable broadcast
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 vote 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; executing each round of consensus step in a circulating way 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 according to 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 the Byzantine fault-tolerant protocol BFT, and the currently known asynchronous Byzantine consensus protocols all depend on the binary consensus directly or indirectly, so that block chains and other distributed systems can achieve the consensus under 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 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 figure1-ABANRespectively, 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 ABA1The target node carries out binary consensus on the proposal to be consensus, ABA, of the consensus node 12And 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, when a target node obtains a consensus result for a to-be-consensus proposal proposed by any of the consensus nodes, the other correct consensus nodes finally obtain the same consensus result for the to-be-consensus proposal, and the distributed system may be a blockchain 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. ABA1The input (initial vote value) of (binary consensus for the proposal to be consensus proposed by consensus node 1) is set to 1 (first vote value) and the binary consensus method proposed in this specification starts to be performed. Under the condition that N-f consensus proposals to be consensus are received, after the ABA process is executed for the N-f consensus proposals to obtain a consensus result of 1, setting the input of the residual ABA of the f consensus proposals to be consensus as 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 that other consensus nodes broadcast the vote value, each consensus node may broadcast the local vote value 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 refer to the related art, and are not described in detail herein. 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 vote value three times, 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.
The target node 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 identification message may be a bvalrAnd (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 nodeReceive f +1 bvalrAnd (3) a message, wherein f +1 pre-vote values carried in the f +1 messages are all 1, and the pre-vote value of the target node which has been broadcast once in the current round of consensus through the first consensus message is 0, which is different from the f +1 pre-vote values, so that the local pre-vote value of the current round of consensus can be modified to 1, and the pre-vote value of the value 1 is broadcast again through the first consensus message. 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 bsetrIf it is determined that 1 is the first to be added to the voting set bset at this timerAnd 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 auxrThe target node may also receive the main vote value broadcast by other consensus nodes, and in order to avoid malicious nodes from intentionally sending false vote values, the target node may perform validity verification on the received main vote value in its turn based on the voting set in its turn, specifically, after receiving the main vote value broadcast by any consensus node, judge that the main vote value is broadcast by any consensus nodeWhether the main voting value is in the local polling set of the current round or not is judged, if so, the second consensus message is legal, namely, the main voting value carried by the second consensus message is legal, and if not, the main voting value carried by the second consensus 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 current rounds are the same, determining the voting values corresponding to the N-f main voting values 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, the third consensus message may be broadcast by using a reliable broadcast RBC protocol with unconditional security, for example, the Bracha's broadcast RBC protocol may be used, and the reliable broadcast RBC protocol is used for broadcasting, so that the security of the consensus process is further improved no matter how strong the computation capability of the adversary is, the broadcast RBC protocol cannot be broken.
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 the next round of consensus, and 1 can be determined as the 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 asynchronouslyThe consensus node in the distributed system can quickly reach the consensus state aiming at a to-be-consensus proposal, and can effectively ensure the security of the consensus process. Each node performs consensus operation according to consensus rounds, wherein in each consensus round, the node only needs to broadcast the consensus message for three times, wherein at least the third broadcast consensus message is broadcasted by adopting a reliable broadcast RBC protocol, 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 each node achieving consensus 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:
Figure BDA0003230096430000131
in the above pseudo code:
each round is divided into three stages:
first stage
(1) Copy piInput iv for its r-th roundrBroadcast pre-voter(ivr) Wherein iv isr∈{0，1}。
(2) When the copy piF +1 pre-votes are received for the same value v in the same round number rr(v) And no prior pre-votes for v in r rounds have been broadcast, copy piThe pre-vote is broadcast.
(3) When the copy pi2f +1 pre-votes are received for the same value v in the same round number rr(v) Then v is inserted into the set bsetrWherein bsetrIs a set consisting of 0 and 1.
Second stage
(1) When set bsetrNot null, copy piFetch bsetrAs v, broadcasts the main vote main-voter(v) In that respect A correct copy is accepted by the main vote-voter(v) If and only if v has been inserted before into the local set bsetrIn (1).
(2) When the copy piReceiving main votes main-votes from N-f different copiesr() And entering the third stage.
The third stage
(1) When the copy piReceive N-f pairs of identityv main voting main-votes in the same round number rr(v) At message time, r-broadcast final vote final-vote for v in r roundr(v) Otherwise copy pir-final vote final-vote broadcast in r roundr(. 1) wherein
Figure BDA0003230096430000141
Is a symbol different from 0 and 1.
Final voting final-voter() For copy piIt is effective only in the following cases:
for a vote final-voter(v) Copy piV has been inserted into bsetr
For final-voter(. about.), copy piBset ofrContaining 0 and 1
(2) When the copy pir-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 polling value of the current round to other nodes of 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 round of pre-vote values to other consensus nodes; the processing module 510 is specifically 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; 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 node are received, where the f +1 local round pre-vote values are all the same and different from the local round pre-vote value, 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 legal main voting values are received, determining a final voting value based on the N-f legal main voting values.
In an embodiment, the processing module 510 is specifically configured to determine, if the N-f legitimate main vote values in the round are the same, a vote value corresponding to the N-f main vote values as a final vote value; 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 voting 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 current rounds, randomly determining a local coin throwing value, wherein the local coin throwing value is a first voting value or a second voting value, and determining the local coin throwing value as a next round of commonly-identified pre-voting value.
The implementation processes of the functions and actions of the components in the device are specifically described in the implementation processes of the corresponding steps in the 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. 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 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).
Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.
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 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 (13)

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; 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 vote values of the current rounds broadcasted by other consensus nodes.
2. The method according to claim 1, wherein said broadcasting the vote value of the current round to other nodes of the N consensus nodes using reliable broadcast RBC protocol broadcast comprises:
broadcasting the pre-voting value of the round to other consensus nodes;
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;
and 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.
3. The method according to claim 2, wherein said reliable broadcast RBC protocol is an unconditionally safe reliable broadcast RBC protocol.
4. The method according to claim 2, wherein before determining the round of master vote values based on the round of pre-vote values broadcast by the other consensus nodes, further comprising:
if f +1 local round pre-voting values broadcasted by other consensus nodes are received, the f +1 local round pre-voting values are the same and are different from the local pre-voting values broadcasted in the local round, 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.
5. The method of claim 4, 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.
6. The method of claim 5, 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.
7. The method of claim 6, wherein determining a final vote value based on the N-f legitimate rounds of master vote values comprises:
if the main voting values of the N-f legal local rounds are the same, determining the voting values corresponding to the N-f main voting values 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.
8. The method of claim 7, wherein the determining the consensus situation of the proposal to be consensus based on the received vote values of the current round broadcasted by the other consensus nodes comprises:
and determining the consensus condition of the proposal to be consensus based on the received final vote value of the current round broadcasted by other consensus nodes by using the reliable broadcast RBC protocol.
9. The method according to claim 8, 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.
10. The method of claim 9, 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 current rounds, randomly determining a local coin throwing value, wherein the local coin throwing value is a first voting value or a second voting value, and determining the local coin throwing value as a next round of commonly-identified pre-voting value.
11. A binary consensus device based on reliable broadcasting is applied to any consensus node in a distributed system, the distributed system at least comprises N consensus nodes, wherein N is larger than or equal to 3f +1, and f is an integer larger 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; wherein the initial vote value comprises a first vote value or a 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 is used for broadcasting the polling value of the current round to other nodes in the N common nodes by using reliable broadcast RBC protocol broadcast;
and the processing module is used for determining the consensus result of the proposal to be consensus based on the received vote values of the current round broadcasted by other consensus nodes.
12. 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 10 when executing the program.
13. 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 10.
CN202110984390.0A 2021-08-25 2021-08-25 Binary consensus method and device based on reliable broadcast Active CN113794694B (en)

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 true CN113794694A (en) 2021-12-14
CN113794694B 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)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114401271A (en) * 2022-01-13 2022-04-26 中国人民解放军国防科技大学 Test data tamper-proof method, block chain system and medium
CN114861233A (en) * 2022-04-19 2022-08-05 湖南天河国云科技有限公司 Fragmented asynchronous Byzantine fault-tolerant consensus method and device without trusted third party
WO2023016428A1 (en) * 2021-08-12 2023-02-16 清华大学 Byzantine fault tolerance method and apparatus, and electronic device and storage medium
WO2023024886A1 (en) * 2021-08-25 2023-03-02 清华大学 Reliable broadcast-based binary consensus method and apparatus, electronic device, and storage medium
CN117354318A (en) * 2023-09-28 2024-01-05 北京航空航天大学 Practical distributed voting consensus method, device, equipment and storage medium

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116455904B (en) * 2023-06-12 2023-09-05 湖南天河国云科技有限公司 Block chain consensus method and system based on asynchronous network decentralization

Citations (4)

* Cited by examiner, † Cited by third party
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
CN110943838A (en) * 2018-09-21 2020-03-31 上海派链信息科技有限公司 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network
KR20200081533A (en) * 2018-12-27 2020-07-08 서강대학교산학협력단 Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment
CN111414373A (en) * 2020-03-18 2020-07-14 深圳市网心科技有限公司 Consensus method and consensus system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
CN111522800B (en) * 2020-07-03 2020-10-30 支付宝(杭州)信息技术有限公司 Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism
CN112286731A (en) * 2020-07-03 2021-01-29 支付宝(杭州)信息技术有限公司 Restarting processing method of block chain consensus node, consensus node and block chain system
CN113794694B (en) * 2021-08-25 2022-08-26 清华大学 Binary consensus method and device based on reliable broadcast

Patent Citations (4)

* Cited by examiner, † Cited by third party
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
CN110943838A (en) * 2018-09-21 2020-03-31 上海派链信息科技有限公司 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network
KR20200081533A (en) * 2018-12-27 2020-07-08 서강대학교산학협력단 Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment
CN111414373A (en) * 2020-03-18 2020-07-14 深圳市网心科技有限公司 Consensus method and consensus system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
YANG XIAO等: "A_Survey_of_Distributed_Consensus_Protocols_for_Blockchain_Networks", 《IEEE》 *
翁良: "异步环境下的拜占庭共识算法研究", 《中国优秀硕士学位论文全文数据库》 *
郭兵勇等: "一个高传输效率的多值拜占庭共识方案", 《密码学报》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023016428A1 (en) * 2021-08-12 2023-02-16 清华大学 Byzantine fault tolerance method and apparatus, and electronic device and storage medium
WO2023024886A1 (en) * 2021-08-25 2023-03-02 清华大学 Reliable broadcast-based binary consensus method and apparatus, electronic device, and storage medium
CN114401271A (en) * 2022-01-13 2022-04-26 中国人民解放军国防科技大学 Test data tamper-proof method, block chain system and medium
CN114861233A (en) * 2022-04-19 2022-08-05 湖南天河国云科技有限公司 Fragmented asynchronous Byzantine fault-tolerant consensus method and device without trusted third party
CN114861233B (en) * 2022-04-19 2023-12-19 湖南天河国云科技有限公司 Fragmenting asynchronous Bayesian family fault-tolerant consensus method and device without trusted third party
CN117354318A (en) * 2023-09-28 2024-01-05 北京航空航天大学 Practical distributed voting consensus method, device, equipment and storage medium
CN117354318B (en) * 2023-09-28 2024-04-05 北京航空航天大学 Practical distributed voting consensus method, device, equipment and storage medium

Also Published As

Publication number Publication date
CN113794694B (en) 2022-08-26
WO2023024886A1 (en) 2023-03-02

Similar Documents

Publication Publication Date Title
CN113794694B (en) Binary consensus method and device based on reliable broadcast
KR102469267B1 (en) Blockchain consensus method, accounting node and node
CN106453415B (en) Block chain-based equipment authentication method, authentication server and user equipment
CN113783935B (en) Byzantine fault-tolerant method and device
CN111490878B (en) Key generation method, device, equipment and medium
CN113783708A (en) Re-voting binary consensus method and device based on reliable broadcast
CN111885050B (en) Data storage method and device based on block chain network, related equipment and medium
CN111639932B (en) Offline resource transfer method and device based on block chain
CN110874650B (en) Alliance learning method, device and system fusing public domain data and private data
CN111985007A (en) Contract signing and executing method and device based on block chain
CN113794576B (en) Re-voting binary consensus method and device
CN112714158A (en) Transaction processing method, relay network, cross-link gateway, system, medium, and device
CN108564363B (en) Transaction processing method, server, client and system
CN111367923A (en) Data processing method, data processing device, node equipment and storage medium
CN114070733A (en) Consensus method, device and system based on block chain network
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
CN113794566B (en) Re-voting binary consensus method, device and storage medium
CN113783946A (en) Re-voting binary consensus method and device based on threshold signature
CN116257882A (en) Voting method, voting system, electronic equipment and storage medium
CN115525930A (en) Information transfer method, device and related equipment
CN111884808B (en) Method and device for preventing transaction cross-chain replay and electronic equipment
CN114760198A (en) Consensus method, device and system based on block chain network
CN113051622A (en) Index construction method, device, equipment and storage medium
CN115499836B (en) Communication method, communication device, electronic equipment, storage medium and vehicle

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