CN113794576B - Re-voting binary consensus method and device - Google Patents

Re-voting binary consensus method and device Download PDF

Info

Publication number
CN113794576B
CN113794576B CN202110925721.3A CN202110925721A CN113794576B CN 113794576 B CN113794576 B CN 113794576B CN 202110925721 A CN202110925721 A CN 202110925721A CN 113794576 B CN113794576 B CN 113794576B
Authority
CN
China
Prior art keywords
value
consensus
voting
values
round
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110925721.3A
Other languages
Chinese (zh)
Other versions
CN113794576A (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 CN202110925721.3A priority Critical patent/CN113794576B/en
Publication of CN113794576A publication Critical patent/CN113794576A/en
Application granted granted Critical
Publication of CN113794576B publication Critical patent/CN113794576B/en
Priority to PCT/CN2022/111002 priority patent/WO2023016429A1/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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

The embodiment of the application provides a two-element consensus method capable of voting again, which is applied to any consensus node in a distributed system, wherein the distributed system at least comprises N consensus nodes, N is more than or equal to 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 voting value and an initial auxiliary value corresponding to the to-be-consensus proposal; under the condition that the initial voting value is other voting values and meets the preset condition, determining the initial voting value as a priority voting value again; broadcasting a first round consensus message carrying an initial voting value and an initial auxiliary value; and agreeing on the priority voting value according to the first-round agreement message broadcast by other agreement nodes for the to-be-agreed proposal and the first-round agreement strategy. By adopting the method of the specification, the consensus nodes can quickly achieve consensus on the prior voting values in the first consensus round, and the consensus efficiency in a distributed system is improved.

Description

Re-voting binary consensus method and device
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 a distributed fault-tolerant system. Therefore, the research on 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, and is used for solving the problem of low consensus efficiency in the prior art.
The embodiment of the application provides a two-element consensus method capable of voting again, which is characterized in that the method is applied to any consensus node in a distributed system, the distributed system at least comprises N consensus nodes, wherein N is more than or equal to 3f +1, 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 voting value and an initial auxiliary value corresponding to the to-be-consensus proposal; wherein the voting value comprises a priority voting value and other voting value; the initial voting value is a 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 a first round consensus message carrying an initial voting value and an initial auxiliary value;
and agreeing on the priority voting value according to the first-round agreement message broadcast by other agreement nodes for the to-be-agreed proposal and the first-round agreement strategy.
According to a second aspect of the embodiments of the present application, a binary consensus device capable of re-voting is applied to any consensus node in a distributed system, where the distributed system at least includes N consensus nodes, where N is greater than or equal to 3f +1, and f is an integer greater than 0, and the device includes:
the processing module is used for determining an initial voting value and an initial auxiliary value corresponding to a proposal to be consensus for any consensus node; wherein the voting value comprises a priority voting value and other voting value; the initial voting value is a 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 is used for broadcasting a first round consensus message carrying an initial voting value and an initial auxiliary value;
and the processing module is further used for achieving consensus on the priority voting value according to the initial consensus information which is broadcast by other consensus nodes and is about to-be-consensus-proposed and the initial consensus strategy.
By adopting the consensus method provided by the embodiment of the application, each consensus node proposes to broadcast the voting value and the auxiliary value in the consensus head round aiming at the consensus, wherein the voting value comprises the priority voting value, and in addition, each consensus node is allowed to determine the initial voting value as the priority voting value again under the condition that the initial voting value is not the priority voting value, so that each consensus node can quickly achieve consensus on the priority voting value in the consensus head round, the consensus efficiency of each consensus node in a 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. 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 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 structural diagram of a re-voted binary 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 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 a 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 two-dimensional consensus method capable of re-voting, which is applied to any consensus node in a distributed system, where the node broadcasts a consensus message including a vote value and an auxiliary value, the vote value includes a priority vote value and other vote values, and when the initial vote value is other vote values, the initial vote value can be modified from other vote values to a priority vote value, and in a first-round consensus, each node can quickly achieve consensus on the priority vote value, thereby improving the consensus efficiency of each consensus node in the system.
The solution in the embodiment of the present application may be implemented by using various computer languages, for example, object-oriented programming language Java and transliteration scripting language JavaScript, etc.
In order to make the technical solutions and advantages in the embodiments of the present application more clearly understood, the following description of the exemplary embodiments of the present application with reference to the accompanying drawings is made in further detail, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all the 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 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. The auxiliary value is an auxiliary opinion provided in the present specification for assisting each node to agree on a pending consensus proposal, and includes at least a priority vote value and other vote values.
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, for a schematic diagram of a binary consensus example to be performed by any consensus node in a distributed system, if N consensus nodes coexist in the distributed system, for convenience of description, any one of the 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 this 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 the target node performs consensus on each to-be-consensus proposal, an initial vote value (0 or 1) is determined, and finally the binary consensus method proposed based on the 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 consensus nodes in the system achieve consensus, so the present 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, and the method is applied to any correct node in the consensus nodes.
The method comprises the following steps:
s201, aiming at a proposal to be consensus of any consensus node, determining an initial voting value and an initial auxiliary value corresponding to the proposal to be consensus;
as shown in fig. 1 and the description of fig. 1, the target node determines the consensus result for each candidate consensus proposal of the consensus node, and the consensus process to be performed by the target node for each candidate consensus proposal is described in fig. 2.
In this step, an initial vote value and an initial auxiliary value are determined for the proposal to be consensus, the auxiliary value may include a priority vote value, other vote values, and null, the initial auxiliary value may default to null, and the initial vote value may be determined according to different data in different application scenarios. For example, in a blockchain network, it may be determined whether a proposal to be consensus is received: if the target node receives the proposal to be identified (other common identification nodes broadcast by the reliable broadcast RBC protocol), the initial vote value of the proposal to be identified is determined as a priority vote value, and if the proposal to be identified of the N-f common identification nodes is determined to be received, the initial vote value of the proposal to be identified which is not received can be set as the other vote values. In other application scenarios, the initial vote value of the proposal to be consensus may also be determined from different data.
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;
s203, broadcasting a first round consensus message carrying the initial voting value and the initial auxiliary value;
and S204, according to the initial consensus information about the proposal to be consensus and the initial consensus strategy broadcast by other consensus nodes, achieving consensus on the priority voting values.
In the above S202, when the target node determines the initial vote value, the target node may perform S203, namely, broadcast the initial vote value and the initial auxiliary value, and receive the initial vote value and the initial auxiliary value broadcast by other consensus nodes for the to-be-consensus suggestion, regardless of whether the initial vote value is the priority vote value or the other vote value.
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.
In addition, in the case that the preset condition is not satisfied, the target node is not allowed to modify the initial vote value, different preset conditions may be flexibly configured in different distributed system application scenarios, taking a blockchain network application scenario with N consensus nodes as an example, the target node may broadcast the to-be-consensus proposal based on the reliable broadcast RBC protocol, and may determine that the initial vote value of the to-be-consensus proposal of the consensus node F1 is other vote values 0 (taking 1 as an example, and taking 0 as an example, and other vote values are indicated by 0) and execute S203 if the to-be-consensus proposal of the F1 has not obtained a consensus result and the target node has received the to-be-consensus proposal if the to-be-consensus proposal of the consensus node F1 has not been received, but the to-be-consensus proposals of other N-F consensus nodes have been received, respectively start to execute S203, the initial vote value may be determined again for the to-be-consensus proposal, i.e. re-determined as a priority vote value. That is, in the context of a blockchain network, the preset conditions may be configured as: if the consensus process is started for the to-be-consensus suggestion and the consensus result of the to-be-consensus suggestion is not obtained yet, the to-be-consensus suggestion is received.
The reliable broadcast RBC protocol can ensure that the target node receives only one time, rather than receiving the same to-be-consensus proposal multiple times, when receiving any one to-be-consensus proposal, so that when the consensus process is already started for a certain to-be-consensus proposal and then the to-be-consensus proposal is received, the initial vote value of the to-be-consensus proposal is indicated to be other vote values 0, further, the initial vote value of the to-be-consensus proposal can be modified to be a priority vote value 1, and the consensus process is triggered to be executed again by taking the priority vote value 1 as an input.
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.
In S203, the target node may specifically execute the steps as shown in fig. 3:
s301, carrying the initial voting value and the initial auxiliary value in the first-class consensus message for broadcasting;
in this step, the initial voting value and the initial auxiliary value may be determined in the above manner, and will not be described in detail here.
The target node may add the locally determined initial voting value and the initial auxiliary value to the first-round first-class consensus message, and transmit the first-round first-class 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 technical facility, which is not limited in this specification. In one embodiment, the first type of consensus message may be bvalrThe message in the form of a message, which the target node can broadcast as bvalr(estr,majr) Message of estrFor the vote value, majrAs auxiliary values, voting values estrIs a binary number (0 or 1), majrE {0,1,. DELTA. }, in the first round, majrSet to null, r is the consensus round, the first round, i.e., round 0, and the consensus round is incremented by 1 from 0.
S302, receiving first-round first-type consensus messages broadcast by other consensus nodes;
it is understood that all correct nodes in the distributed system are executing the steps performed by the target node, i.e. other consensus nodes will also send an initial round of consensus messages including the initial vote value and the initial auxiliary value for the proposal to be consensus; at this time, the target node receives first round first type consensus messages sent by other consensus nodes.
In one embodiment, if the target node receives f +1 first-class consensus messages in the first-round consensus, that is, the first-round first-class consensus messages exceeding the number of malicious nodes, if the vote values in the f +1 first-class consensus messages are the same and are inconsistent with the locally broadcast vote value, the target node modifies the local vote value of the current round to the vote value in the f +1 first-class consensus messages, and broadcasts the first-round first-class consensus messages again. For example, if the target node receives f +1 bval0(b, -) message, and b is not equal to the current round of first broadcast vote value for the target node that will broadcast bval0(b,⊥)。
And S303, re-determining the voting value and the auxiliary value based on the initial voting value and the first-class consensus message broadcasted by other consensus nodes, and carrying the re-determined voting value and the auxiliary value in the first-class second-class consensus message for broadcasting.
Each common node only sends the second-type common message once in each round, and the specific way of determining the information carried in the second-type common message may be as follows:
in one embodiment, the initial vote value broadcasted locally through the first-type consensus message for the first time can be added to the first set in the case that the initial vote value is a priority vote value; and determining the voting values in the first set as the voting values in the first round of second-type consensus message and the auxiliary value.
In connection with the above example, the target node broadcasts a bval0(est0,maj0) 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,1). Wherein auxrIn a second type of consensus message format.
In an embodiment, when an initial vote value broadcasted by a target node through a first-class consensus message for the first time is not a priority vote value, if f +1 first-class consensus messages broadcasted by other consensus nodes are received and vote values carried in the f +1 first-class consensus messages are all priority vote values, adding the priority vote value to a first set of first rounds, and determining the vote values in the first set of first rounds as the vote value and an auxiliary value in a second-class consensus message of first rounds.
For example, the target node receives f +1 bval0(b,. t) message, where b ═ 1, i.e. the preferred vote value, then b is stored in bin _ values0(ii) a If the target node has not sent aux at this time0() Message, then broadcast aux0(1,1)。
In an embodiment, when an initial vote value broadcasted by a target node through a first-class consensus message is not a priority vote value, if a legal number of first-class consensus messages broadcasted by other consensus nodes are received and vote values carried in the legal number of first-class consensus messages are not the priority vote value, that is, all the vote values are other vote values, adding the other vote values to a first set of first rounds, and determining the vote values in the first set of first rounds as a vote value and an auxiliary value in a second-class consensus message of first rounds. The quorum is 2f +1 consensus nodes (including self nodes), and if no special provisions exist, the quorum is 2f +1 hereinafter.
For example, the target node received 2f +1 bval0(b,. t) message, where b is 0, i.e. not the priority vote value, the target node adds b to the set bin _ values0If the target node has not yet issued aux at this time0() Message, then broadcast aux0(0,0)。
In the above manner, after the target node locally sends the priority vote value through the first type consensus message, the priority vote value sent through the second type consensus message can be directly sent without referring to the opinions of other consensus nodes, so that each node can quickly achieve consensus on the priority vote value, and meanwhile, after re-voting, the consensus step performed on the priority vote value can exceed the consensus step performed on other vote values.
After receiving the first round second-type consensus messages broadcast by other consensus nodes, the target node may determine whether consensus can be achieved on the priority vote value according to a first round consensus strategy, where the first round consensus strategy is a strategy that enables each consensus node to rapidly achieve consensus on the priority vote value in a first round.
In one embodiment, the first round consensus strategy may specifically be:
after receiving a quorum of the first-round second-type consensus messages, storing voting values in the received second-type consensus messages into a first-round second set, and storing auxiliary values into a first-round third set; setting the first-round public money throwing value as the priority voting value;
under the condition that only one voting value is contained in the first round second set, if more than (N + f +1)/2 second-class consensus messages carrying the priority voting values are received, determining the consensus result as the priority voting value; and if more than (N + f +1)/2 second-class consensus messages carrying other voting values are received, setting the voting values and the auxiliary values carried in the first-class consensus messages in the next round as the other voting values.
For example, the target node is receiving N-f auxs0() After the message (first round second type consensus message), the target node will receive the aux0() The vote value and the auxiliary value in the message are both stored in vals0(first round second set) and avals0(first round third set). If, set vals0Contains only b, where b is 0 or 1, and more than (N + f +1)/2 aux of the same b are received0(b, can be any value of 0,1 or in the air, and b ═ 1 (preferential vote value), then the consensus result is determined to be 1; if b is 0, the target node will be estr+1(vote value of next consensus round) with majr+1(the assistance value of the next consensus round) is set to b.
In addition, if more than (N + f +1)/2 second-class consensus messages carrying the same vote value are not received, setting the vote value and the auxiliary value carried in the first-class consensus message of the next round as the priority vote value.
With reference to the above example, if the target node does not receive more than (N + f +1)/2 second-type consensus messages carrying the same vote value, the est is sentr+1And majr+1Are set to 1.
Therefore, by adopting the first round consensus strategy, each consensus node can quickly achieve consensus on the prior voting value, and the consensus efficiency is improved.
The above-mentioned S201 to S204 are the first round of consensus, and the following describes other round of consensus:
except for the first round, the consensus of the other rounds is achieved by adopting the method shown in fig. 4:
in the case that the first round does not agree on the priority vote value, then the loop execution S401-S402 may be started until the consensus result for the to-be-consensus proposal is obtained:
s401, broadcasting a current round of consensus information, wherein the consensus information carries a current round of voting value and an auxiliary value;
s402, whether a consensus result is obtained is determined based on the received voting value and the auxiliary value broadcast by other consensus nodes for the proposal to be consensus.
Wherein, in S401, specifically, may be:
s401a, carrying the voting value and the auxiliary value in the first-class consensus message for broadcasting;
s401b, receiving a first type consensus message broadcast by other consensus nodes;
s401c, re-determining the vote value and the auxiliary value based on the received first-type consensus message, and broadcasting the re-determined vote value and auxiliary value carried in the second-type consensus message.
The processes of S401a-S401b may refer to the contents of S301-S302, which are not described in detail herein, and only differ from the voting values and the auxiliary values carried in the first-type consensus message that are not the initial voting values and the initial auxiliary values, but are the voting values and the auxiliary values that are re-determined based on the message transmission result after the first-round consensus, which may specifically refer to the above-mentioned part related to S204, which is not described in detail herein.
In S401c, the target node may re-determine the vote value and the auxiliary value according to the received first-type consensus message after receiving the quorum of first-type consensus messages.
Specifically, if the vote value in the 2f +1 first-type consensus messages is 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 valuesrIn (1). In addition, the target node adds the auxiliary value in the 2f +1 first-class consensus messages to the auxiliary value set majs. In this step, in the case that a quorum of the same vote values is received, then the vote values are stored in the first set, meaning that most nodes in the system may have agreed. The target node may compare the vote value in the first set with the common vote value of the previous round, and determine the vote value and the auxiliary value carried in the second type consensus message according to the comparison result. The common coin throwing value is only 0 or 1, each consensus node can obtain 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 here.
The specific manner of determining the vote value and the auxiliary value carried in the second type consensus message according to the comparison result may be as follows:
if the voting value in the first set is equal to the common coin throwing value of the previous round, the voting values carried in the first type of consensus messages received by the target node are all the voting values in the first set, and the carried auxiliary values are all the voting values in the first set or null, setting the voting values and the auxiliary values in the second type of consensus messages as the voting values in the first set and broadcasting; and if the first type of consensus information carrying other voting values is received, setting the voting value in the second type of consensus information to be null, and setting the auxiliary value in the second type of consensus information to be the voting value in the first set.
Continuing with the above example, if the vote value in the first set is b, the common cast value of the previous round is Sr-1If b is equal to Sr-1And the target node receives only bvalr(b, b) and bvalr(b,. Tp.) message, then aux is broadcast directlyr(b, b) if a first type consensus message carrying other voting values has also been received, broadcasting auxr(⊥,b)。
If the vote value in the first set is not equal to the common vote value of the previous round and the vote value and the auxiliary value carried in the first-class consensus message received by the target node are both the vote value in the first set, setting the vote value and the auxiliary value in the second-class consensus message as the vote value in the first set and broadcasting; and if the first type of consensus messages carrying other voting values or auxiliary values are also received, setting the voting value in the second type of consensus messages to be null, and setting the auxiliary value in the second type of consensus messages to be the voting value in the first set. Continuing with the above example, if the vote value in the first set is b, the common cast value of the previous round is Sr-1If, if
Figure GDA0003559693690000121
Wherein the content of the first and second substances,
Figure GDA0003559693690000122
since the cast value has only two values 0 or 1 and the vote value has only two values 0 or 1, the cast value S is not equal to the cast value br-1When it is equal to 1-Sr-1Namely, it is
Figure GDA0003559693690000123
In this case, and the target node has received only bvalr(b, b) message, then directly broadcast auxr(b, b) broadcasting aux if a first type consensus message carrying other voting values or auxiliary values has also been receivedr(⊥,b)。
And each common identification node only broadcasts the second common identification information once in each turn, and the mode is a mode of determining the voting value and the auxiliary value carried in the second type of common identification information of the non-first turn for the target node.
When the target node sends the second type of consensus message, the target node receives the second type of consensus message sent by other consensus nodes because other consensus nodes also send the second type of consensus message asynchronously. After receiving the consensus messages sent by other consensus nodes, the target node can delete some obvious and illegal second-class consensus messages, and according to the contents, the correct consensus node only broadcasts the message with the form of auxr(b, b) and auxrAnd the second-type consensus messages of (T, b) can be directly discarded when messages carrying other voting values or auxiliary values are received, and because the voting values in the second-type consensus messages are stored in the first set, legal and illegal messages can be determined by using the first set after the second-type consensus messages are received.
In the above S402, the target consensus node determines whether a consensus result is obtained based on the received vote value and the auxiliary value, and if the consensus result is not obtained, determines a vote value and an auxiliary value of a next round, and re-starts to perform S401.
The following details a method for determining the consensus result by the target consensus node based on the received vote value and the auxiliary value, and determining the vote value and the auxiliary value in the next round:
the target node receives a quorum of the second type of consensus vanishesAfter receiving the second type of common identification message, the voting value and the auxiliary value in the received second type of common identification message can be stored into a second set of vals respectivelyrAnd a third set of avalsrAnd obtaining a common money throwing value unified by all the consensus nodes in the round. For example, the target node is receiving 2f +1 auxr() After the message, the received aux can be sentr() Storing the vote value and the auxiliary value in the message into a set vals respectivelyrSecond set) and avalsr(third set). The target node may determine the consensus result, or the vote value and the auxiliary value carried by the first type of consensus message in the next round of consensus according to the received second type of consensus message in the following manner:
(a) if the second type of consensus information which exceeds the legal quantity is the same in the second type of consensus information received by the target node, and the voting value in the second type of consensus information is the same as the auxiliary value, the target node compares the voting value in the second type of consensus information with the current round of public coin throwing value, and if the voting value is the same as the current round of public coin throwing value, the target consensus node determines that the consensus result is the voting value; if not, the target node sets the voting values and the auxiliary values carried in the first-class consensus messages of the next round as the voting values in the second-class consensus messages, and starts to execute the next round of consensus.
For example, if the target node receives a quorum bar auxr(b, b) information that the target node throws the money S between b and the local roundrA comparison is made. If b is equal to SrDetermining a consensus result as b by the target node; otherwise, the target node will be estr+1And majr+1All set to b and proceed to the next round of consensus.
(b) And if the target node only receives the legal second-class consensus messages, the voting values in the second set are one voting value and null, and the auxiliary values of at least a legal number of second-class consensus messages are the voting values, respectively comparing the voting values with the common coin-throwing values of the previous and current rounds of consensus. And if the vote value is the same as the common coin throwing value of the previous round and the current round, the target node determines that the consensus result is the vote value, and if the vote value is not the same as the common coin throwing value of the previous round and/or the coin throwing value of the current round, the target node sets the vote value and the auxiliary value in the first-class consensus message of the next round as the vote value and starts to execute the next round of consensus.
For example, if the target node only received auxr(b,. and aux)r(. quadrature.,) and at least a quorum of the second type of consensus messages is auxr(x, b), the target node throws the money S with b and two rounds in commonr-1And SrA comparison is made. If b is Sr-1And b is SrIf the target node determines that the consensus result is b, otherwise, the target node sends estr+1And majr+1All set to b and proceed to the next round.
(c) If the target node receives legal second-class consensus information with legal quantity, the auxiliary values carried by the legal second-class consensus information are not completely the same, the voting value in the second set is a voting value and null, and the voting value is the same as the previous round of common voting value, the target consensus node sets the voting value and the auxiliary value in the first-class consensus information in the next round of consensus as the voting value, and starts to execute the next round of consensus. For example, if the target node receives N-f auxsr(b,. and aux)rMessage containing auxr(. 0) and auxr(. 1), and b ═ Sr-1Then the target node will estr+1And majr+1All set to b and proceed to the next round of consensus.
(d) If the situation of the second-type consensus message received by the target node does not belong to the three situations, the target node can use the current round of the common coin throwing value as the voting value of the next round of the first-type consensus message. And the target node sets the auxiliary value in the first common message of the next round as a value of which the occurrence times in the second set exceed the preset times, and enters the next round of consensus.
For example, if the second type of consensus message received by the target node does not belong to the three cases, the target node takes the current round of common cast value as the next round of input (i.e., est)r+1Is set as Sr). In addition, if the round number r is equal to 0, the target node will be majr+1Is set as Sr(ii) a If r>0, the target node maps majr+1Set to majauthority (vals)r) Wherein, majauthority (vals)r) B, b ∈ {0,1}, where b is in valsrThe most frequent occurrence of them, i.e. valsrThe number of b in (1) is not less than
Figure GDA0003559693690000141
If there is no such b, let majority (vals)r)＝⊥。
It can be understood that the above-mentioned manner is a method executed by any correct node in the consensus nodes, and other correct consensus nodes also execute the above-mentioned method asynchronously, and by adopting the above-mentioned manner, the priority vote value is set, and in the first round, each consensus node can achieve consensus on the priority vote value with a large probability, so that each consensus node in the distributed system under the asynchronous environment can rapidly achieve the consensus state on 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 value 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; the consensus is as follows: 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 correct set of nodes, whereQ1 is the set of correct nodes that broadcast the vote value of 1 without rebroadcasting the vote value of 0, Q2 is the set of correct nodes that broadcast the vote value of 0 and rebroadcast the vote value of 1, if
Figure GDA0003559693690000151
And Q1 ═ Q2, then all correct nodes agree;
integrity: the correct node agrees only once with a proposal.
After the consensus proposals made for all consensus nodes have agreed, each correct consensus node will get the same consensus result, resulting in a sequence comprising 0 and 1. 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, there are four consensus nodes, the consensus proposal proposed by the consensus node 1 is P1, the consensus proposal proposed by the consensus node 2 is P2, the consensus proposal proposed by the consensus node 3 is P3, and the consensus proposal proposed by the consensus node 4 is P4, and after performing consensus by using the above consensus method, a 01 sequence is obtained, for example, the obtained sequence is (1,1,1,0), and then the consensus result is achieved 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 proposal according to the consensus result, thereby ensuring data consistency of each consensus node.
In order to make the above binary consensus method more clear for those skilled in the art, the following describes the process of the target node receiving the pending consensus proposals from other consensus nodes and sending the pending consensus proposals to other consensus nodes, taking a blockchain scenario as an example:
the target node may randomly obtain a preset number of transactions from the local transaction pool, or preferentially obtain a preset number of transactions stored earlier according to the 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 following is an example of a specific implementation of the reliable broadcast RBC protocol:
the target node can adopt erasure code processing to the proposal to be identified to obtain N data blocks; constructing a Merck tree based on the obtained hash values of the N data blocks to obtain root hash and a Merck proof of a Merck path corresponding to each data block; and storing part of the N data blocks in the local, and sending the Merckel paths corresponding to other data blocks, the root hash and other data blocks to other consensus nodes so that the other consensus nodes broadcast and verify the data blocks. Taking a total of 4 consensus nodes (consensus node 1-consensus node 4) as an example, a target node is a consensus node 1, the consensus node 1 splits a local proposal to be consensus into 4 data blocks, namely data block 1-data block 4, after erasure code processing, Hash operation is performed on the 4 data blocks by using a preset Hash algorithm to obtain Hash values of the 4 data blocks, a merkel tree is constructed based on the Hash values of the 4 data blocks, the Hash value of the data block 1 is Hash1, the Hash value of the data block 2 is Hash2, the Hash value of the data block 3 is Hash3, the Hash value of the data block 4 is Hash4, Hash1 and Hash2 are calculated to obtain Hash12, Hash3 and Hash4 are calculated to obtain Hash34, Hash12 and Hash34 are calculated to obtain a root Hash, and thus a merkel tree is obtained. It is understood that the above is only 4 nodes, and in practical applications, a more complex merkel tree can be constructed according to different numbers of common nodes. After the mercker tree is constructed, the consensus node 1 can store the data block 1 locally, and send the data block 2, the Hash1, the Hash34 and the root Hash to the consensus node 2; sending the data block 3, the Hash4, the Hash12 and the root Hash to the consensus node 3; the data block 4, Hash3, Hash12, and root Hash are sent to consensus node 4. Taking the content sent to the consensus node 2 as an example, the Hash1 and the Hash34 are the mercker certificates of the mercker paths corresponding to the data block 2. The common node 1 may transmit the above contents to other common nodes in a format of a Rval message. After receiving the content sent by the consensus node 1, the other consensus nodes may broadcast the content to the other consensus nodes in an Echo message format. After receiving the Echo message, other common identification nodes may verify whether the message is legal, specifically, after receiving the message, for a data block in the message, verify by using a mercker certificate and a root hash of a mercker path corresponding to the data block; if the verification passes, the message is determined to be legitimate.
Continuing the above example, after receiving the Echo message, the consensus node 3 determines that the message content is: the data block 4, the Hash3, the Hash12 and the root Hash can be calculated to obtain a Hash4, the Hash4 and the received Hash3 are calculated to obtain a Hash34, the Hash34 and the received Hash12 are calculated to obtain the root Hash, if the calculated root Hash is the same as the received root Hash, the Echo message is legal, and if the verification fails, the Echo message can be directly discarded to avoid tampering the message by malicious nodes.
Through the above manner, the consensus node 2-the consensus node 4 can receive all data blocks sent by the consensus node 1 (target node) (in the case that no node intentionally sends no data block), any node can select any N-2f data blocks to restore the proposal to be consensus after receiving N-f Echo messages and under the condition that the N-f Echo messages are verified to pass, reconstruct the mercker tree, compare whether the root Hash of the mercker tree obtained by reconstruction is consistent with the root Hash in the Echo received before, and broadcast the Ready message if the root Hash is consistent.
It can be understood that, although the target node 1 is described as an example, in the consensus method shown in this specification, each consensus node has no primary or secondary part, that is, any consensus node is a target node, and any consensus node can obtain a to-be-consensus proposal of other consensus nodes in the above manner; any consensus node sends the local to-be-consensus proposal to other consensus nodes in the above manner.
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. After receiving the proposals to be consensus from other consensus nodes, the target node may determine the initial vote value of the proposal to be consensus, and may perform the methods shown in fig. 2 to 4 for all the proposals to be consensus, that is, may determine the initial vote value of each proposal to be consensus according to the receiving condition of the proposal to be consensus to trigger the execution of the re-voted binary consensus method proposed in this specification, and may further achieve consensus for the proposals to be consensus broadcast by each consensus node in the block chain network.
It should be understood that, the above is only a specific implementation manner of the reliable broadcast RBC protocol, and specific contents of the reliable broadcast RBC protocol that can also be implemented in other manners may refer to related technologies, which are not limited in this specification. In addition, the above is also an example of applying the two-element consensus method capable of re-voting provided in this specification to a blockchain network, and in other application scenarios, the initial voting value of any one of the proposals to be consensus-voted may be determined based on different data, and the two-element consensus method capable of re-voting provided in this specification may be performed to make each consensus node achieve consensus.
S201 to S204 in the present specification will be described below from the code implementation perspective:
the pseudo code is as follows:
Figure GDA0003559693690000181
Figure GDA0003559693690000191
in the above pseudo-code, each RABA protocol instance is syntactically marked with a unique identifier sid. This example consists of pro (si,), reproose (si,), and decide (si,), where the input variable space is {0,1 }. For our purposes, RABA is "biased towards 1". At the beginning of the protocol each copy may have a dispose value v. Each copy can only be deployed once. Proposing that the correct copy of 0 is allowed to change ideas and reprocess 1; but a copy of proposal 1 does not allow replay 0. (i.e., the correct copy to run under the protocol does not). At most, repropose1 is made once per copy. For each instance specified by the sid, the replica terminates the execution of the instance after generating the decide message.
As shown in fig. 5, 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 520, configured to determine, for a to-be-consensus proposal of any consensus node, an initial vote value and an initial auxiliary value corresponding to the to-be-consensus proposal; wherein the voting value comprises a priority voting value and other voting value; the initial voting value is a 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;
a communication module 510, configured to broadcast a first-round consensus message carrying an initial vote value and an initial auxiliary value;
the processing module 520 is further configured to agree on the priority vote value according to the first-round consensus message for the to-be-consensus proposal and the first-round consensus strategy broadcast by other consensus nodes.
In one embodiment, the processing module 520 is further configured to, in a case that the first round does not agree on the priority vote value, loop the following steps until obtaining a consensus result for the to-be-consensus proposal: calling a communication module 510 to broadcast the consensus information of the current round, wherein the consensus information carries the voting value of the current round and the auxiliary value; and determining whether the consensus result is obtained or not based on the received voting values and auxiliary values broadcasted by other consensus nodes.
In an embodiment, the processing module 520 is specifically configured to invoke the communication module 510 to carry the initial vote value and the initial auxiliary value in the first-class consensus message for broadcasting, and receive the first-class consensus message broadcasted by other consensus nodes; and based on the initial vote value and the initial round first-class consensus messages broadcast by other consensus nodes, re-determining the vote value and the auxiliary value, and invoking the communication module 510 to carry the re-determined vote value and the auxiliary value in the initial round second-class consensus messages for broadcasting.
In an embodiment, the processing module 520 is specifically configured to, when f +1 first-class consensus messages are received, and the vote values in the f +1 first-class consensus messages are the same and different from the initial vote value of the local broadcast, modify the local initial vote value to the vote value in the f +1 first-class consensus messages, and broadcast the first-class consensus message carrying the initial vote value and the initial auxiliary value again.
In an embodiment, the processing module 520 is specifically configured to, in a case that the initial vote value is a priority vote value, add the initial vote value to the first initial-round set, and determine the vote values in the first initial-round set as the vote value and the auxiliary value in the second initial-round consensus message.
In an embodiment, the processing module 520 is specifically configured to, when the initial vote value is not a priority vote value, add the priority vote value to a first set of first rounds if f +1 first-class consensus messages broadcasted by other consensus nodes are received and vote values carried in the f +1 first-class consensus messages are all priority vote values, and determine the vote values in the first set of first rounds as a vote value and an auxiliary value in a second first-class consensus message of the first rounds.
In an embodiment, the processing module 520 is further configured to, if a legal number of first-class consensus messages broadcasted by other consensus nodes are received and the vote values carried in the legal number of first-class consensus messages are all other vote values, add the other vote values to the first initial-class set and determine the vote values in the first initial-class set as the vote values and the auxiliary values in the second initial-class consensus messages.
In an embodiment, the processing module 520 is specifically configured to agree on the preferred vote value based on the vote value, the auxiliary value, and the first-round consensus policy in the received first-round second-type consensus message.
In one embodiment, the first round consensus strategy comprises: after receiving a quorum of the first-round second-type consensus messages, storing voting values in the received second-type consensus messages into a first-round second set, storing auxiliary values into a first-round third set, and setting a first-round public coin throwing value as the priority voting value; under the condition that the first round second set only contains one voting value, if more than (N + f +1)/2 second-class consensus messages carrying priority voting values are received, determining a consensus result as the priority voting value; if more than (N + f +1)/2 second-class consensus messages carrying other voting values are received, setting the voting values and the auxiliary values carried in the first-class consensus messages of the next round as other voting values;
and if not receiving more than (N + f +1)/2 second-class consensus messages carrying the same vote value, setting the vote value and the auxiliary value carried in the first-class consensus message of the next round as the priority vote value.
In an embodiment, the communication module 510 is specifically configured to carry the vote value and the auxiliary value in a first type consensus message for broadcasting; receiving a first type of consensus messages broadcast by other consensus nodes; the processing module 520 is configured to re-determine the vote value and the auxiliary value based on the received first-class consensus message, and the communication module 510 is specifically configured to carry the re-determined vote value and the auxiliary value in the second-class consensus message for broadcasting.
In an embodiment, the processing module 520 is further configured to modify the vote value to the vote value in the f +1 first-type consensus messages if f +1 first-type consensus messages are received in the current consensus round, and the vote value in the f +1 first-type consensus messages is the same and is different from the vote value broadcast by the local current consensus round through the first-type consensus messages, and broadcast the first-type consensus messages carrying the vote value and the auxiliary value again.
In an embodiment, the processing module 520 is specifically configured to, after receiving the quorum of the first-type consensus messages, add the vote value to the first set of the current round if the vote values carried by the quorum of the first-type consensus messages are the same; and comparing the voting value in the first set of the current round with the public coin throwing value of the previous round, and re-determining the voting value and the auxiliary value according to the comparison result and the received first-class consensus message.
In an embodiment, the processing module 520 is specifically configured to, when the vote value in the first set of the current round is equal to the common cast value in the previous round, if the vote values carried in the received first-type consensus message are all vote values in the first set, and the auxiliary values carried in the received first-type consensus message are all vote values in the first set or are all null, set the vote value and the auxiliary values as the vote values in the first set of the current round; otherwise, the vote value is set to null and the auxiliary value is set to the vote value in the first set of the current round.
In an embodiment, the processing module 520 is specifically configured to, in a case that a vote value in a first set of a current round is not equal to a common cast value of a previous round, set the vote value and an auxiliary value in a second type of consensus message as vote values in a first set of the current round if the vote value and the auxiliary value carried in the received first type of consensus message are both vote values in the first set of the current round; otherwise, the vote value is set to null and the auxiliary value is set to the vote value in the first set.
In an embodiment, the processing module 520 is specifically configured to determine whether a consensus result is obtained based on the vote value and the auxiliary value in the received second-type consensus message.
In an embodiment, the processing module 520 is specifically configured to, if there are more than a legal number of second-type consensus messages in the received second-type consensus messages that are the same and the vote value in the second-type consensus messages is the same as the auxiliary value, compare the vote value in the second-type consensus messages with the round common cast money value, and if the vote value is the same as the round common cast money value, determine that the consensus result is the vote value by the target consensus node; and if not, setting the voting value and the auxiliary value carried in the next round of the first-class consensus messages as the voting value in the second-class consensus message.
In an embodiment, the processing module 520 is specifically configured to, if only the legal second-type consensus messages are received, the vote values in the second set are a vote value and null, and at least a legal number of auxiliary values of the second-type consensus messages are the vote value, compare the vote value with the common vote values of the previous round of consensus and the current round of consensus, respectively; if the voting value is the same as the common coin throwing values of the previous round and the current round, the target node determines that the consensus result is the voting value; if the voting value is different from the previous round of the common coin throwing value and/or the current round of the coin throwing value, the voting value and the auxiliary value in the next round of the first-type consensus message are set as the voting value.
In an embodiment, the processing module 520 is specifically configured to, if a legal second-type consensus message of a legal quantity is received, the auxiliary values carried by the legal second-type consensus messages are different, the vote value in the second set is one vote value and null, and the vote value is the same as the previous round of common vote value, set both the vote value and the auxiliary value in the first-type consensus message in the next round of consensus as the vote value.
In an embodiment, the processing module 520 is specifically configured to, when the received second-type consensus message does not satisfy the foregoing embodiment, take the current round of the common vote value as the vote value of the next round of the first-type consensus message; and setting the auxiliary value in the first common message of the next round as a value of which the occurrence number in the second set exceeds a preset number.
The implementation processes of the functions and actions of each component in the above device are specifically described in the implementation processes of the corresponding steps in the above method, and are not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described apparatus embodiments are merely illustrative. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the 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. 1.
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 specification.
The Memory 1020 may be implemented in a ROM (Read ONly Memory), a RAM (RaNdom Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component within the device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and the output devices may include a display, speaker, vibrator, 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. 1.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a traNsitory computer readable medium (traNsitory media) 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, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop, 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, the apparatus embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the description of the method embodiments for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to realize the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement 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 (19)

1. A two-element consensus method capable of voting again 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 more than or equal to 3f +1, 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 voting value and an initial auxiliary value corresponding to the to-be-consensus proposal; the voting value comprises a priority voting value and other voting values; the initial voting value is a priority voting value or other voting values; under the condition that the initial voting value is other voting values, if the proposal to be identified is received and the identification result of the proposal to be identified is not obtained, determining the initial voting value as a priority voting value again;
carrying the initial voting value and the initial auxiliary value in the first-class consensus message for broadcasting; receiving first-round first-type consensus messages broadcast by other consensus nodes; if the broadcasted initial voting value is a priority voting value, or if the broadcasted initial voting value is not the priority voting value and f +1 first-class consensus messages carrying the initial voting value as the priority voting value and broadcasted by other consensus nodes are received, determining the priority voting value as the voting value and the auxiliary value in the first-class second-class consensus messages, and broadcasting the first-class second-class consensus messages;
after receiving a quorum of first-round second-type consensus messages, storing voting values in the received second-type consensus messages into a first-round second set, and if more than (N + f +1)/2 second-type consensus messages carrying priority voting values are received under the condition that the first-round second set only contains one voting value, determining the consensus result as the priority voting value.
2. The method of claim 1, further comprising:
in case of no agreement on the priority vote value in the first round, the following steps are executed in a loop until an agreement result for the proposal to be agreed is obtained:
broadcasting a current round of consensus information, wherein the consensus information carries a current round of voting values and auxiliary values;
and determining whether a consensus result is obtained or not based on the received voting values and auxiliary values broadcasted by other consensus nodes for the proposal to be consensus.
3. The method of claim 1, further comprising, prior to determining the vote value and the auxiliary value in the first round second type consensus message:
if f +1 first-class consensus messages are received, and the voting values in the f +1 first-class consensus messages are the same and different from the initial voting value of local broadcasting, modifying the local initial voting value into the voting value in the f +1 first-class consensus messages, and broadcasting the first-class consensus messages carrying the initial voting value and the initial auxiliary value again.
4. The method of claim 1, further comprising:
and under the condition that the initial voting value is not a priority voting value, if a legal number of first-class consensus messages broadcasted by other consensus nodes are received and the voting values carried in the legal number of first-class consensus messages are all other voting values, adding the other voting values into a first initial-class set, and determining the voting values in the first initial-class set as the voting values and auxiliary values in a second initial-class consensus message.
5. The method of claim 4, further comprising: and if more than (N + f +1)/2 second-class consensus messages carrying other voting values are received, setting the voting values and the auxiliary values carried in the first-class consensus messages of the next round as the other voting values.
6. The method of claim 5, further comprising:
and if the number of the second-type consensus messages which carry the same voting value is not more than (N + f +1)/2, setting the voting value and the auxiliary value carried in the first-type consensus message in the next round as the priority voting value.
7. The method of claim 2, wherein the broadcasting the current round consensus message comprises:
carrying the voting value and the auxiliary value in the first type consensus information for broadcasting;
receiving a first type of consensus information broadcast by other consensus nodes;
and re-determining the voting value and the auxiliary value based on the received first-type consensus message, and carrying the re-determined voting value and the auxiliary value in the second-type consensus message for broadcasting.
8. The method of claim 7, wherein before re-determining the vote value and the auxiliary value based on the received consensus message of the first type, further comprising:
if f +1 first-type consensus messages are received in the current consensus round, the voting values in the f +1 first-type consensus messages are the same and different from the voting values broadcast by the local round consensus through the first-type consensus messages, the voting values are modified into the voting values in the f +1 first-type consensus messages, and the first-type consensus messages carrying the voting values and the auxiliary values are broadcast again.
9. The method of claim 8, wherein re-determining the vote value and the auxiliary value based on the received consensus message of the first type comprises:
after receiving a quorum of the first-type consensus messages, adding the voting values to a first set of the current round under the condition that the voting values carried by the quorum of the first-type consensus messages are the same;
and comparing the voting value in the first set of the current round with the public coin throwing value of the previous round, and re-determining the voting value and the auxiliary value according to the comparison result and the received first-class consensus message.
10. The method of claim 9, wherein the re-determining the vote value and the auxiliary value according to the comparison result and the received consensus message of the first type comprises:
under the condition that the voting value in the first set of the current round is equal to the public coin throwing value in the previous round, if the voting value carried in the received first-class consensus message is the voting value in the first set and the carried auxiliary value is the voting value in the first set or null, setting the voting value and the auxiliary value as the voting value in the first set of the current round; otherwise, the vote value is set to null and the auxiliary value is set to the vote value in the first set of the current round.
11. The method of claim 10, further comprising:
under the condition that the voting value in the first set of the current round is not equal to the public coin throwing value in the previous round, if the voting value and the auxiliary value carried in the received first type of consensus message are both the voting value in the first set of the current round, setting the voting value and the auxiliary value in the second type of consensus message as the voting value in the first set; otherwise, the vote value is set to null and the auxiliary value is set to the vote value in the first set.
12. The method of claim 11, wherein determining whether to obtain the consensus result based on the received vote value and the auxiliary value broadcasted by the other consensus nodes comprises:
and determining whether a consensus result is obtained based on the voting value and the auxiliary value in the received second-type consensus message.
13. The method as claimed in claim 12, wherein the determining whether the consensus result is obtained based on the vote value and the auxiliary value in the received second type consensus message comprises:
after receiving a quorum of second-class consensus messages, storing voting values and auxiliary values in the received second-class consensus messages into a second set and a third set respectively, and obtaining a uniform public coin throwing value of all consensus nodes in the round;
if the second type of consensus messages exceeding the legal quantity are the same in the received second type of consensus messages and the vote value in the second type of consensus messages is the same as the auxiliary value, comparing the vote value in the second type of consensus messages with the round of common vote value, and if the vote value is the same as the round of common vote value, determining that the consensus result is the vote value by the target consensus node; and if not, setting the voting value and the auxiliary value carried in the next round of the first-class consensus messages as the voting value in the second-class consensus message.
14. The method of claim 13, further comprising:
if only legal second-class consensus messages are received, the voting values in the second set are a voting value and null, and the auxiliary values of at least a legal number of second-class consensus messages are the voting values, respectively comparing the voting values with the common coin-throwing values of the previous and current rounds of consensus;
if the voting value is the same as the common coin throwing values of the previous round and the current round, determining the consensus result as the voting value; if the voting value is different from the previous round of the common coin throwing value and/or the current round of the coin throwing value, the voting value and the auxiliary value in the next round of the first-type consensus message are set as the voting value.
15. The method of claim 14, further comprising:
if a legal second-type consensus information with a legal quantity is received, the auxiliary values carried by the legal second-type consensus information are different, the voting value in the second set is a voting value and null, and the voting value is the same as the previous round of common voting value, and the voting value and the auxiliary value in the first-type consensus information in the next round of consensus are both set as the voting value.
16. The method of claim 15, further comprising:
if the received second consensus message comprises a priority voting value and other voting values, or auxiliary values carried by legal second type consensus messages of legal quantity received by the target node are different, the voting values in the second set are a voting value and null, and the voting value is different from the previous round of public money throwing value, taking the current round of public money throwing value as the voting value of the next round of first type consensus messages; and setting the auxiliary value in the first common message of the next round as a value of which the occurrence number in the second set exceeds a preset number.
17. 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:
the processing module is used for determining an initial voting value and an initial auxiliary value corresponding to the proposal to be consensus for any consensus node; wherein the voting value comprises a priority voting value and other voting value; the initial voting value is a priority voting value or other voting values; if the initial voting value is other voting values, if the proposal to be identified is received and the identification result of the proposal to be identified is not obtained, determining the initial voting value as a priority voting value again;
the communication module is used for carrying the initial voting value and the initial auxiliary value in the first-class consensus message of the first round for broadcasting; receiving first-round first-type consensus messages broadcast by other consensus nodes;
the processing module is configured to determine the priority vote value as a vote value and an auxiliary value in a first-round second-kind consensus message if the broadcasted initial vote value is a priority vote value, or if the broadcasted initial vote value is not the priority vote value and f +1 first-round first-kind consensus messages carrying the initial vote value as the priority vote value and broadcasted by other consensus nodes are received;
the communication module is used for broadcasting the first round second type consensus information;
the processing module is further configured to store the vote values in the received second-type consensus messages into a first-round second set after receiving a quorum of first-round second-type consensus messages, and determine that the consensus result is the preferred vote value if more than (N + f +1)/2 second-type consensus messages carrying preferred vote values are received under the condition that the first-round second set only contains one vote value.
18. A computer device comprising a memory, a processor, a communication interface, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 16 when executing the program.
19. A computer-readable storage medium, characterized in that a computer program is stored thereon which, when being executed by a processor, carries out the method according to any one of claims 1 to 16.
CN202110925721.3A 2021-08-12 2021-08-12 Re-voting binary consensus method and device Active CN113794576B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202110925721.3A CN113794576B (en) 2021-08-12 2021-08-12 Re-voting binary consensus method and device
PCT/CN2022/111002 WO2023016429A1 (en) 2021-08-12 2022-08-09 Binary consensus method and apparatus capable of revoting, electronic device, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110925721.3A CN113794576B (en) 2021-08-12 2021-08-12 Re-voting binary consensus method and device

Publications (2)

Publication Number Publication Date
CN113794576A CN113794576A (en) 2021-12-14
CN113794576B true CN113794576B (en) 2022-07-19

Family

ID=78875990

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110925721.3A Active CN113794576B (en) 2021-08-12 2021-08-12 Re-voting binary consensus method and device

Country Status (2)

Country Link
CN (1) CN113794576B (en)
WO (1) WO2023016429A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113794576B (en) * 2021-08-12 2022-07-19 山东区块链研究院 Re-voting binary consensus method and device
CN113783708A (en) * 2021-08-25 2021-12-10 山东区块链研究院 Re-voting binary consensus method and device based on reliable broadcast

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109347804A (en) * 2018-09-19 2019-02-15 电子科技大学 A kind of Byzantine failure tolerance common recognition optimization method for block chain
CN110708171A (en) * 2019-12-13 2020-01-17 腾讯科技（深圳）有限公司 Block chain consensus voting method, device, equipment and storage medium
CN111416708A (en) * 2020-03-16 2020-07-14 北京有链科技有限公司 Block chain Byzantine fault-tolerant consensus method and system
CN111522800A (en) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10503614B2 (en) * 2017-04-21 2019-12-10 Vmware, Inc. Byzantine agreement using communications having linear complexity
WO2019226099A1 (en) * 2018-05-23 2019-11-28 Haj Enterprise Ab A system and a method for achieving consensus between multiple parties on an event
CN111682942B (en) * 2020-05-18 2022-06-10 哈尔滨工业大学 Binary weighted Byzantine fault-tolerant consensus method applied to license chain
CN113794576B (en) * 2021-08-12 2022-07-19 山东区块链研究院 Re-voting binary consensus method and device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109347804A (en) * 2018-09-19 2019-02-15 电子科技大学 A kind of Byzantine failure tolerance common recognition optimization method for block chain
CN110708171A (en) * 2019-12-13 2020-01-17 腾讯科技（深圳）有限公司 Block chain consensus voting method, device, equipment and storage medium
CN111416708A (en) * 2020-03-16 2020-07-14 北京有链科技有限公司 Block chain Byzantine fault-tolerant consensus method and system
CN111522800A (en) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Chao Liu ; Sisi Duan ; Haibin Zhang.EPIC: Efficient Asynchronous BFT with Adaptive Security.《2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)》.2020, *
异步环境下的拜占庭共识算法研究;翁良;《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》;20200215;全文 *

Also Published As

Publication number Publication date
WO2023016429A1 (en) 2023-02-16
CN113794576A (en) 2021-12-14

Similar Documents

Publication Publication Date Title
CN113783935B (en) Byzantine fault-tolerant method and device
CN113810465B (en) Asynchronous binary consensus method and device
US11265173B2 (en) Methods and systems for consensus in blockchains
CN111782275B (en) Transaction processing method and device based on blockchain and electronic equipment
US11336451B2 (en) Cross-blockchain resource transmission
CN113794694B (en) Binary consensus method and device based on reliable broadcast
CN111382168B (en) Node group creating method and node group-based transaction method in alliance chain network
US10938565B2 (en) Method and apparatus for inter-blockchain transmission of authenticable message
CN113794576B (en) Re-voting binary consensus method and device
CN113783708A (en) Re-voting binary consensus method and device based on reliable broadcast
CN108550038A (en) A kind of data dissemination system and method applied to block chain
CN111526216A (en) Consensus method and system in alliance chain
US20210158344A1 (en) Blockchain smart contract-based data processing
CN114070733B (en) Consensus method, device and system based on block chain network
CN111669434B (en) Method, system, device and equipment for establishing communication group
CN112988470B (en) Consensus method, consensus node and system in alliance chain
CN113794566B (en) Re-voting binary consensus method, device and storage medium
CN113783946A (en) Re-voting binary consensus method and device based on threshold signature
CN114760198B (en) Consensus method, device and system based on block chain network
CN111884808B (en) Method and device for preventing transaction cross-chain replay and electronic equipment
CN114331442B (en) Calling method and device of intelligent contracts in block chain
CN114780987B (en) Data distribution, storage, reading and transmission method and distributed system
CN114331447B (en) Cross-link message submitting method and device
CN115577039A (en) Block processing method, block processing device, verification node and storage medium
CN117670548A (en) Transaction execution method, blockchain system, blockchain node and storage medium

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