EP3933645B1 - Blockchain consensus method, node, and system based on honey badger byzantine fault tolerance consensus mechanism - Google Patents

Blockchain consensus method, node, and system based on honey badger byzantine fault tolerance consensus mechanism Download PDF

Info

Publication number
EP3933645B1
EP3933645B1 EP21181539.4A EP21181539A EP3933645B1 EP 3933645 B1 EP3933645 B1 EP 3933645B1 EP 21181539 A EP21181539 A EP 21181539A EP 3933645 B1 EP3933645 B1 EP 3933645B1
Authority
EP
European Patent Office
Prior art keywords
consensus
proposals
votes
node
equal
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
EP21181539.4A
Other languages
German (de)
French (fr)
Other versions
EP3933645A1 (en
Inventor
Xiaojun Liao
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.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
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 Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Publication of EP3933645A1 publication Critical patent/EP3933645A1/en
Application granted granted Critical
Publication of EP3933645B1 publication Critical patent/EP3933645B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/21—Design, administration or maintenance of databases
    • G06F16/214—Database migration support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30—Decision processes by autonomous network management units using voting and bidding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • This document relates to the field of blockchain technologies, and in particular, to a blockchain consensus method, node, and system based on a Honey Badger Byzantine fault tolerance (BFT) consensus mechanism.
  • BFT Honey Badger Byzantine fault tolerance
  • the Honey Badger BFT consensus mechanism reaches consensus by using a binary agreement (BA) protocol.
  • BA protocol is a random and indeterministic algorithm and includes three stages, in which consensus nodes exchange consensus opinions for the first time, then exchange consensus opinions for the second time, which is conducive to convergence, and finally, make a decision through coin tossing to reach consensus. In the coin tossing stage, if a unified result from one round of coin tossing is not reached, a next round of coin tossing needs to be initiated.
  • this application proposes a consensus solution with a higher efficiency for the Honey Badger BFT consensus mechanism.
  • An objective of the embodiments of this specification is to provide a blockchain consensus method, node, and system based on a Honey Badger BFT consensus mechanism, which can implement consensus at a higher efficiency based on the Honey Badger BFT consensus mechanism.
  • a consensus node based on a Honey Badger BFT consensus mechanism including:
  • a blockchain system based on a Honey Badger BFT consensus mechanism including a plurality of consensus nodes, where:
  • a consensus node of a blockchain initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • a Honey Badger BFT consensus mechanism reaches consensus by using a binary agreement (BA) protocol.
  • the BA protocol is a random and indeterministic algorithm and includes three stages of exchanging consensus opinions between consensus nodes the first time, exchanging consensus opinions the second time for convergence, and making a decision finally through coin tossing to implement consensus. In the coin tossing stage, if a unified result from one round of coin tossing is not reached, a next round of coin tossing needs to be initiated.
  • BA protocol due to the uncertainty of the BA protocol, initiating a plurality of rounds of message exchange in a case of an uncontrollable network may lead to a decrease in a consensus efficiency. In view of this, this application proposes a consensus solution with a higher efficiency for the Honey Badger BFT consensus mechanism.
  • FIG. 1 is a flowchart of a blockchain consensus method based on a Honey Badger BFT consensus mechanism, according to an embodiment of this specification.
  • the method shown in FIG. 1 may be performed by a corresponding apparatus below and includes the following steps: S102: A target consensus node performs a current round of consensus, to count consensus votes of N consensus proposals.
  • a consensus vote of a target consensus node for a target consensus proposal represents a consensus opinion of the target consensus node for the target consensus proposal, if the target consensus node opposes (disapproves) the target consensus proposal, an opposition consensus vote is cast; otherwise, if the target consensus node agrees with the target consensus proposal, an agreement consensus vote is cast.
  • the target consensus node traverses a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes (an empty set in a first round), and f is a number of fault tolerant consensus nodes.
  • the target consensus node starts to traverse the first set.
  • one consensus proposal has one and only one type of consensus votes (opposition consensus votes or agreement consensus votes) reaching a number greater than or equal to 2f+1, and a corresponding consensus result is a result indicated by the consensus votes of the number greater than or equal to 2f+1. That is, a consensus proposal that receives greater than or equal to 2f+1 identical consensus votes is a consensus proposal on which consensus has been reached already, a consensus proposal that receives greater than or equal to f+1 and less than 2f+1 identical consensus votes is a consensus proposal on which consensus is about to be reached, and a consensus proposal that does not include f+1 identical consensus votes is a consensus proposal on which consensus is far from being reached.
  • a consensus proposal that receives greater than or equal to 2f+1 identical consensus votes is a consensus proposal on which consensus has been reached already
  • a consensus proposal that receives greater than or equal to f+1 and less than 2f+1 identical consensus votes is a consensus proposal on which consensus is about to be reached
  • a consensus proposal that does not include f+1 identical consensus votes is a consensus
  • the target consensus node traverses a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus.
  • the target consensus node may trace consensus opinions based on the erasure coding algorithm, and if the consensus opinions can be traced, the consensus opinions are migrated into the second set and are updated to agreement consensus opinions, to cast agreement consensus votes in a next round of consensus; and if the consensus opinions cannot be traced, the consensus opinions are migrated into the third set and are updated to opposition consensus opinions, to cast opposition consensus votes in a next round of consensus.
  • the erasure coding algorithm described herein and usage thereof belong to a technology of the existing Honey Badger BFT, and are not described in this specification again.
  • the target consensus node may directly migrate the consensus proposal to the third set and update consensus opinions in the third set to opposition consensus opinions.
  • the fourth set includes only consensus opinions that receive opposition consensus votes, even when a number of votes does not reach f+1, the consensus opinions are directly migrated into the second set and updated to opposition consensus opinions.
  • this type of consensus proposals may be considered as consensus nodes on which opposition opinions are about to be reached and are stored in the second set.
  • Consensus Messages may be configured for the first set and the fourth set.
  • a Consensus Message transmitted by the target consensus node includes: a field value of consensus votes of consensus proposals in the fourth set and a field value of consensus votes of consensus proposals in the first set that are locally recorded by the target consensus node.
  • the target consensus node merges the second set into the first set, and merges the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes.
  • a consensus process is performed for a plurality of rounds of iterations.
  • the target consensus node may update consensus opinions of some consensus proposals, to cast consensus votes different from those of the previous round of consensus in the next round of consensus, thereby affecting a consensus result.
  • the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes, it indicates that the N consensus proposals all have a condition of reaching consensus, and the target consensus node exits the plurality of rounds of iterations in this case.
  • the target consensus node determines a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • a consensus node of a blockchain initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • the blockchain consensus method of the embodiments of this specification is mainly divided into two stages: Stage 1: A consensus node transmits, based on a reliable broadcast (RBC) protocol, a consensus proposal initiated by the consensus node.
  • RBC reliable broadcast
  • Stage 2 Collect an RBC result of the consensus proposal and perform certainty consensus.
  • a related data structure is defined as follows:
  • a sequence of a consensus node may be represented by using a subscript value.
  • consensus votes of consensus proposals of the Unconfirmed_Proposals set are recorded.
  • a root hash of a consensus proposal may be used to represent an agreement consensus vote, and ⁇ is used to represent an opposition consensus vote.
  • consensus votes of consensus proposals of the Confirmed_Proposals set are recorded.
  • a root hash of a consensus proposal may be used to represent an agreement consensus vote, and ⁇ is used to represent an opposition consensus vote.
  • a root hash of a consensus proposal initiated by the consensus node A is a1
  • a root hash of a consensus proposal initiated by a consensus node B is b1
  • a root hash of a consensus proposal initiated by the consensus node C is c1
  • a root hash of a consensus proposal initiated by the consensus node D is d1
  • the consensus node D receives 2f+1 Consensus Messages in a first round of consensus:
  • Confirmed_Proposals may also record a result whether consensus is reached, which is represented by using 0 or 1, and if consensus may be reached on a consensus vote of one consensus proposal, the value of the result is 1, otherwise, the value of the result is 0.
  • FIG. 2 A main procedure of the consensus method of the embodiments of this specification is shown in FIG. 2 and includes the following steps:
  • ConsensMessage.Unconfirmed_Proposals field of the Consensus Message is filled by using information recorded in the Unconfirmed_Proposals, a ConsensMessage.Confirmed_Proposals field is set to null, Round is set to 0, and the Consensus Message is broadcast to other consensus nodes.
  • Step 4 The target consensus node performs step 5 after receiving the Consensus Messages transmitted by the other consensus nodes in the same manner and obtaining 2f+1 Consensus Messages of the same round including the Consensus Message of the target consensus node.
  • Step 5 The target consensus node traverses consensus proposals of the set C: The target consensus node first determines whether the set C stores N consensus proposals and whether each consensus proposal includes 2f+1 same root hashes. If yes, this batch of iteration is ended, and the set C is used as a consensus result set of the N consensus proposals; otherwise, the following steps are performed: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 same root hashes into a temporary Confirmed_Proposals set (that is, the foregoing second set, and hereinafter referred to as a set C ⁇ for short); migrating consensus proposals that each receive less than f+1 identical consensus votes into a temporary Unconfirmed Proposals set (that is, the foregoing third set, and hereinafter referred to as a set U ⁇ for short), and updating root hashes to null to represent opposition consensus opinions. If all the consensus proposals are traversed completely, step 6 is performed sequentially.
  • Step 6 Traverse consensus proposals of the set U:
  • Step 7 Merge the set C ⁇ back into the set C to generate a new set C, merge the set U ⁇ back into the set U to generate a new set U, increase Round by 1, fill an Unconfirmed_Proposals field and a Confirmed_Proposal field in the Consensus Message by using the new set C and the new set U, and broadcast the Consensus Message. Subsequently, go back to step 4.
  • FIG. 3 is a schematic structural diagram of the consensus node 300, and the consensus node includes:
  • a consensus node initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • the consensus node further includes: an RBC protocol module, configured to transmit, based on an epoch message in an RBC protocol, consensus proposals initiated by the target consensus node to other consensus nodes, and after consensus proposals transmitted by 2f other consensus nodes through the epoch message are received, trace, based on the erasure coding algorithm, remaining consensus proposals not received, where in the first round of consensus, the target consensus node casts opposition consensus votes for consensus proposals that are untraceable based on the erasure coding algorithm in an RBC protocol stage and casts agreement consensus votes for remaining consensus proposals.
  • an RBC protocol module configured to transmit, based on an epoch message in an RBC protocol, consensus proposals initiated by the target consensus node to other consensus nodes, and after consensus proposals transmitted by 2f other consensus nodes through the epoch message are received, trace, based on the erasure coding algorithm, remaining consensus proposals not received, where in the first round of consensus, the target consensus node casts opposition consensus votes for consensus proposals that are untraceable based on
  • the second set traversing module 330 when performed, is further configured to migrate consensus proposals that each receive only opposition consensus votes into the second set.
  • the consensus node further includes: a consensus synchronization module, configured to exchange a Consensus Message respectively with other consensus nodes to count the consensus votes of the N consensus proposals, where the Consensus Message transmitted by the target consensus node includes: a field value of consensus votes of consensus proposals in the fourth set and a field value of consensus votes of consensus proposals in the first set that are locally recorded by the target consensus node.
  • a consensus synchronization module configured to exchange a Consensus Message respectively with other consensus nodes to count the consensus votes of the N consensus proposals, where the Consensus Message transmitted by the target consensus node includes: a field value of consensus votes of consensus proposals in the fourth set and a field value of consensus votes of consensus proposals in the first set that are locally recorded by the target consensus node.
  • a field value of consensus votes of a consensus proposal agreed by the target consensus node in the Consensus Message is a root hash corresponding to the consensus proposal, and a field value of consensus votes of a consensus proposal opposed by the target consensus node in the Consensus Message is 0.
  • Consensus Message further includes: a field value used for indicating a serial number of a consensus view and/or a field value used for indicating a consensus round.
  • the first set traversing module 320 starts to traverse the first set.
  • the consensus node further includes: a control module, configured to: after the first set traversing module 320 traverses the first set, determine whether the first set stores the N consensus proposals and whether the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes, and if yes, end the consensus; otherwise, control the second set traversing module 330 to start to traverse the fourth set.
  • a control module configured to: after the first set traversing module 320 traverses the first set, determine whether the first set stores the N consensus proposals and whether the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes, and if yes, end the consensus; otherwise, control the second set traversing module 330 to start to traverse the fourth set.
  • any consensus proposal has one and only one type of consensus votes of a number greater than or equal to 2f+1, and a corresponding consensus result is a result indicated by the consensus votes of the number greater than or equal to 2f+1.
  • the consensus node of this embodiment of this specification may be used as an entity for performing the blockchain consensus method shown in FIG. 1 . Therefore, the consensus node can implement functions achieved in the blockchain consensus method in FIG. 1 and FIG. 2 . Due to the same principle, the functions are not repeated herein again.
  • FIG. 4 is a schematic structural diagram of a blockchain system 400.
  • the blockchain system includes a plurality of consensus nodes 410.
  • Any target consensus node 411 in the plurality of consensus nodes 410 counts consensus votes of N consensus proposals during performing a current round of consensus.
  • the target consensus node 411 traverses a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes.
  • the target consensus node 411 traverses a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus.
  • the target consensus node 411 merges the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes.
  • the target consensus node 411 determines a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • a consensus node initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • the blockchain system of this embodiment of this specification may be used as an entity for performing the blockchain consensus method shown in FIG. 1 . Therefore, the blockchain system can implement functions achieved in the blockchain consensus method in FIG. 1 and FIG. 2 . Due to the same principle, the functions are not repeated herein again.
  • FIG. 5 is a schematic structural diagram of an electronic device, according to an embodiment of this specification.
  • the electronic device includes a processor, and optionally includes an internal bus, a network interface, and a memory.
  • the memory may include an internal memory, such as a high-speed random access memory (RAM), and may further include a non-volatile memory, such as at least one disk storage.
  • the electronic device may further include hardware required for other services.
  • the processor, the network interface, and the memory may be connected to each other through an internal bus.
  • the internal bus may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or the like.
  • ISA industry standard architecture
  • PCI peripheral component interconnect
  • EISA extended industry standard architecture
  • the bus may be classified as an address bus, a data bus, a control bus, or the like.
  • ISA industry standard architecture
  • PCI peripheral component interconnect
  • EISA extended industry standard architecture
  • the bus may be classified as an address bus, a data bus, a control bus, or the like.
  • bidirectional arrow is used for indication in FIG. 5 , but it does not mean that there is only one bus or one type of bus.
  • the memory is configured to store a program.
  • the program may include program code, and the program code includes computer operation instructions.
  • the memory may include an internal memory and a non-volatile memory, and provide an instruction and data to the processor.
  • the processor reads a corresponding computer program from the non-volatile memory to the internal memory and then runs the corresponding computer program, and forms the consensus node shown in FIG. 3 on a logical level.
  • the processor executes the program stored in the memory and is configured to perform the following operations:
  • the foregoing blockchain consensus method disclosed in the embodiment shown in FIG. 1 of this specification may be applicable to the processor or implemented by the processor.
  • the processor may be an integrated circuit chip, and has a signal processing capability. During implementation, the steps of the foregoing method may be completed through an integrated logic circuit of hardware or an instruction in the form of software in the processor.
  • the foregoing processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), and the like; or may be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, a discrete gate or a transistor logic device, or a discrete hardware component.
  • the general-purpose processor may be a microprocessor, or the processor may be any conventional processor or the like.
  • the steps of the method disclosed in combination with the embodiments of this specification may be directly embodied as being performed by a hardware decoding processor, or performed by a combination of hardware and software modules in the decoding processor.
  • the software module may be stored in a storage medium that is mature in the art, such as a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable ROM, an electrically erasable programmable memory, or a register.
  • the storage medium is located in the memory.
  • the processor reads information in the memory and completes the steps of the methods in combination with hardware thereof.
  • the electronic device of this specification does not exclude other implementations, such as a logic device or a combination of software and hardware.
  • an entity for performing the following processing flow is not limited to each logic unit, and may alternatively be the hardware or logic device.
  • an embodiment of this specification further provides a computer-readable storage medium storing one or more programs.
  • the one or more programs include instructions.
  • the instructions when executed by a portable electronic device including a plurality of application programs, can cause the portable electronic device to perform the method of the embodiment shown in FIG. 1 and can be configured to perform the following method:
  • the foregoing instructions when executed by the portable electronic device that includes the plurality of application programs, can cause the consensus node shown in FIG. 3 to implement the functions of the embodiments shown in FIG. 1 to FIG. 2 , which is not described herein again.
  • this specification may be provided as a method, a system, or a computer program product. Therefore, this specification may use a form of hardware only embodiments, software only embodiments, or embodiments with a combination of software and hardware. Moreover, this specification may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, a CD-ROM, an optical memory, and the like) that include computer-usable program code.
  • computer-usable storage media including but not limited to a disk memory, a CD-ROM, an optical memory, and the like

Description

    TECHNICAL FIELD
  • This document relates to the field of blockchain technologies, and in particular, to a blockchain consensus method, node, and system based on a Honey Badger Byzantine fault tolerance (BFT) consensus mechanism.
    • BACKGROUND
  • Currently, many blockchain systems implement consensus based on a BFT algorithm. As an emerging asynchronous BFT consensus mechanism, Honey Badger BFT has an advantage of being independent of the time condition of a network environment and has an extremely high processing efficiency, and will develop into a mainstream consensus mechanism in the future.
  • At present, the Honey Badger BFT consensus mechanism reaches consensus by using a binary agreement (BA) protocol. The BA protocol is a random and indeterministic algorithm and includes three stages, in which consensus nodes exchange consensus opinions for the first time, then exchange consensus opinions for the second time, which is conducive to convergence, and finally, make a decision through coin tossing to reach consensus. In the coin tossing stage, if a unified result from one round of coin tossing is not reached, a next round of coin tossing needs to be initiated. Under this background, this application proposes a consensus solution with a higher efficiency for the Honey Badger BFT consensus mechanism.
    • SUMMARY
  • An objective of the embodiments of this specification is to provide a blockchain consensus method, node, and system based on a Honey Badger BFT consensus mechanism, which can implement consensus at a higher efficiency based on the Honey Badger BFT consensus mechanism.
  • In order to achieve the foregoing objective, the embodiments of this specification are implemented in the following manner:
    • According to a first aspect, a blockchain consensus method based on a Honey Badger BFT consensus mechanism is provided, including:
    • performing, by a target consensus node, a current round of consensus, to count consensus votes of N consensus proposals;
    • traversing, by the target consensus node, a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
    • traversing, by the target consensus node, a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
    • merging, by the target consensus node, the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes; and
    • determining, by the target consensus node, a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • According to a second aspect, a consensus node based on a Honey Badger BFT consensus mechanism is provided, including:
    • a consensus vote counting module, configured to perform a current round of consensus, to count consensus votes of N consensus proposals;
    • a first traversing module, configured to traverse a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
    • a second traversing module, configured to traverse a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
    • a set update module, configured to merge the second set into the first set, and merge the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes; and
    • a consensus result determining module, configured to determine a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • According to a third aspect, a blockchain system based on a Honey Badger BFT consensus mechanism is provided, including a plurality of consensus nodes, where:
    • a target consensus node in the plurality of consensus nodes counts consensus votes of N consensus proposals during performing a current round of consensus;
    • the target consensus node traverses a first set to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
    • the target consensus node traverses a fourth set to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
    • the target consensus node merges the second set into the first set and merges the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes; and
    • the target consensus node determines a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • Based on the solutions of the embodiments of this specification, a consensus node of a blockchain initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
    • BRIEF DESCRIPTION OF THE DRAWINGS
  • To describe the technical solutions in the embodiments of this specification or in the prior art more clearly, the accompanying drawings required for describing the embodiments or the prior art are briefly introduced below. Apparently, the accompanying drawings in the following description show merely some embodiments of this specification, and a person of ordinary skill in the art may still derive other accompanying drawings from these accompanying drawings without creative efforts.
    • FIG. 1 is a first schematic flowchart of a blockchain consensus method, according to an embodiment of this specification.
    • FIG. 2 is a second schematic flowchart of a blockchain consensus method, according to an embodiment of this specification.
    • FIG. 3 is a schematic structural diagram of a consensus node, according to an embodiment of this specification.
    • FIG. 4 is a schematic structural diagram of a blockchain system, according to an embodiment of this specification.
    • FIG. 5 is a schematic structural diagram of an electronic device, according to an embodiment of this specification.
    DETAILED DESCRIPTION
  • To enable a person skilled in the art to better understand the technical solutions in this specification, the technical solutions of the embodiments of this specification will be described clearly and thoroughly below with reference to the accompanying drawings of the embodiments of this specification. Apparently, the described embodiments are merely some rather than all of the embodiments of this specification. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of this specification without creative efforts shall fall within the protection scope of this specification.
  • As described above, at present, a Honey Badger BFT consensus mechanism reaches consensus by using a binary agreement (BA) protocol. The BA protocol is a random and indeterministic algorithm and includes three stages of exchanging consensus opinions between consensus nodes the first time, exchanging consensus opinions the second time for convergence, and making a decision finally through coin tossing to implement consensus. In the coin tossing stage, if a unified result from one round of coin tossing is not reached, a next round of coin tossing needs to be initiated. For a blockchain system, due to the uncertainty of the BA protocol, initiating a plurality of rounds of message exchange in a case of an uncontrollable network may lead to a decrease in a consensus efficiency. In view of this, this application proposes a consensus solution with a higher efficiency for the Honey Badger BFT consensus mechanism.
  • FIG. 1 is a flowchart of a blockchain consensus method based on a Honey Badger BFT consensus mechanism, according to an embodiment of this specification. The method shown in FIG. 1 may be performed by a corresponding apparatus below and includes the following steps:
    S102: A target consensus node performs a current round of consensus, to count consensus votes of N consensus proposals.
  • In the Honey Badger BFT consensus mechanism, consensus nodes in a blockchain initiate respective consensus proposals, that is, a total number of the consensus nodes in the blockchain is also N.
  • In each round of consensus, the consensus nodes all need to broadcast respective consensus votes on N consensus proposals to other consensus nodes through Consensus Messages. It should be understood that, a consensus vote of a target consensus node for a target consensus proposal represents a consensus opinion of the target consensus node for the target consensus proposal, if the target consensus node opposes (disapproves) the target consensus proposal, an opposition consensus vote is cast; otherwise, if the target consensus node agrees with the target consensus proposal, an agreement consensus vote is cast.
  • S104: The target consensus node traverses a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes (an empty set in a first round), and f is a number of fault tolerant consensus nodes.
  • In this step, after the Consensus Messages transmitted by 2f other consensus nodes are counted (that is, 2f+1 consensus votes in total including a consensus vote by the target consensus node), the target consensus node starts to traverse the first set.
  • In the Honey Badger BFT consensus mechanism, one consensus proposal has one and only one type of consensus votes (opposition consensus votes or agreement consensus votes) reaching a number greater than or equal to 2f+1, and a corresponding consensus result is a result indicated by the consensus votes of the number greater than or equal to 2f+1. That is, a consensus proposal that receives greater than or equal to 2f+1 identical consensus votes is a consensus proposal on which consensus has been reached already, a consensus proposal that receives greater than or equal to f+1 and less than 2f+1 identical consensus votes is a consensus proposal on which consensus is about to be reached, and a consensus proposal that does not include f+1 identical consensus votes is a consensus proposal on which consensus is far from being reached.
  • S106: The target consensus node traverses a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus.
  • In this step, to expedite reaching consensus on a consensus proposal that receives greater than or equal to f+1 and less than 2f+1 identical consensus votes, the target consensus node may trace consensus opinions based on the erasure coding algorithm, and if the consensus opinions can be traced, the consensus opinions are migrated into the second set and are updated to agreement consensus opinions, to cast agreement consensus votes in a next round of consensus; and if the consensus opinions cannot be traced, the consensus opinions are migrated into the third set and are updated to opposition consensus opinions, to cast opposition consensus votes in a next round of consensus. It should be noted that, the erasure coding algorithm described herein and usage thereof belong to a technology of the existing Honey Badger BFT, and are not described in this specification again.
  • In addition, for a consensus proposal that does not include f+1 identical consensus votes in the fourth set, it indicates that the consensus nodes in the blockchain cannot reach an agreement. Therefore, in order to expedite consensus, the target consensus node may directly migrate the consensus proposal to the third set and update consensus opinions in the third set to opposition consensus opinions.
  • In addition, if the fourth set includes only consensus opinions that receive opposition consensus votes, even when a number of votes does not reach f+1, the consensus opinions are directly migrated into the second set and updated to opposition consensus opinions. In general, if a consensus vote is opposed by more than one consensus node, the consensus vote is most likely opposed by other consensus nodes. Therefore, this type of consensus proposals may be considered as consensus nodes on which opposition opinions are about to be reached and are stored in the second set.
  • In addition, Consensus Messages may be configured for the first set and the fourth set. For example, a Consensus Message transmitted by the target consensus node includes: a field value of consensus votes of consensus proposals in the fourth set and a field value of consensus votes of consensus proposals in the first set that are locally recorded by the target consensus node.
  • S108: The target consensus node merges the second set into the first set, and merges the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes.
  • It should be understood that, a consensus process is performed for a plurality of rounds of iterations. In S104 and S106, the target consensus node may update consensus opinions of some consensus proposals, to cast consensus votes different from those of the previous round of consensus in the next round of consensus, thereby affecting a consensus result. When the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes, it indicates that the N consensus proposals all have a condition of reaching consensus, and the target consensus node exits the plurality of rounds of iterations in this case.
  • S110. The target consensus node determines a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • As described above, when a number of one type of consensus votes of one consensus proposal reaches 2f+1, it indicates that the consensus result of the consensus proposal is a result represented by the consensus votes. For example, when one consensus proposal includes greater than or equal to 2f+1 opposition consensus votes, the consensus result of the consensus proposal fails and the proposal data thereof is not added to the blockchain.
  • Based on the blockchain consensus method shown in FIG. 1 of this embodiment, a consensus node of a blockchain initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • The following describes the blockchain consensus method of the embodiments of this specification in detail.
  • The blockchain consensus method of the embodiments of this specification is mainly divided into two stages:
    Stage 1: A consensus node transmits, based on a reliable broadcast (RBC) protocol, a consensus proposal initiated by the consensus node.
  • In this stage, a consensus proposal is transmitted by using an existing RBC protocol, an erasure coding technology used in this protocol can effectively reduce network bandwidth of an initiator, and the technology is not described in detail in this specification again since the technology is an existing technology.
  • Stage 2: Collect an RBC result of the consensus proposal and perform certainty consensus. A related data structure is defined as follows:
    1. 1) View: a batch number of a consensus view, that is, a serial number of a newly generated block after the consensus is completed.
    2. 2) Round: a number of rounds performed in View consensus. A default value is 0 and is automatically increased by 1 every time a new round of consensus vote is initiated.
    3. 3) Unconfirmed_Proposals (that is, the foregoing fourth set, and hereinafter referred to as the a set U for short): storing consensus proposals that have completed the RBC protocol and related information (for example, root hash) in a first round of consensus, and storing consensus proposals that cannot be confirmed and related information in subsequent rounds of consensus.
    4. 4) Confirmed_Proposals (that is, the foregoing first set, and hereinafter referred to as a set C for short): an empty set in the first round of consensus, and used for reserving consensus proposals that receive greater than or equal to 2f+1 identical consensus votes in the subsequent rounds of consensus. When the set C stores N consensus proposals and each consensus proposal includes 2f+1 identical consensus votes, this batch of iteration is ended.
    5. 5) Consensus Message: used for exchanging consensus votes among consensus nodes. A structure of the Consensus Message is as follows:
 struct ConsensusMessage {
     Nodeld sender;
     Seq seq;
     Round round;
     vector[proposal hash] Unconfirmed_Proposals;
     vector[proposal hash] Confirmed_Proposals;
 }
  • Note: In the two arrays Unconfirmed_Proposals and Confirmed_Proposals, a sequence of a consensus node may be represented by using a subscript value. In an Unconfirmed_Proposals field, consensus votes of consensus proposals of the Unconfirmed_Proposals set are recorded. Herein, a root hash of a consensus proposal may be used to represent an agreement consensus vote, and Ø is used to represent an opposition consensus vote. In a Confirmed_Proposals field, consensus votes of consensus proposals of the Confirmed_Proposals set are recorded. Similarly, a root hash of a consensus proposal may be used to represent an agreement consensus vote, and Ø is used to represent an opposition consensus vote.
  • For example:
    It is assumed that there are four consensus nodes A, B, C, and D, a root hash of a consensus proposal initiated by the consensus node A is a1, a root hash of a consensus proposal initiated by a consensus node B is b1, a root hash of a consensus proposal initiated by the consensus node C is c1, a root hash of a consensus proposal initiated by the consensus node D is d1, and the consensus node D receives 2f+1 Consensus Messages in a first round of consensus:
    • {sender:A,Seq:100,round:0,Unconfirmed_Proposals{a1,null,c1,d1},Confirmed_Proposal s{}};
    • {sender:C,Seq:100,round:0,Unconfirmed_Proposals{a1,null,c1,d1},Confirmed_Proposal s{}};
    • {sender:D,Seq:100,round:0,Unconfirmed_Proposals{a1,b1,c1,d1},Confirmed_Proposals {}};
    • where sender records an identifier of a consensus node, and Seq records a serial number of a consensus view. Information recorded in the Unconfirmed_Proposals is as follows:
      • a proposal of the consensus node A: {a1:3}, which represents 3 agreement consensus votes;
      • a proposal of the consensus node B: {null:3}, which represents 3 opposition consensus votes:
        • a proposal of the consensus node C: {c1:3}, which represents 3 agreement consensus votes; and
        • a proposal of the consensus node D: {d1:2, d2:1}, which represents 2 agreement consensus votes and 1 opposition consensus vote.
  • In addition, the Confirmed_Proposals may also record a result whether consensus is reached, which is represented by using 0 or 1, and if consensus may be reached on a consensus vote of one consensus proposal, the value of the result is 1, otherwise, the value of the result is 0.
  • A main procedure of the consensus method of the embodiments of this specification is shown in FIG. 2 and includes the following steps:
    • Step 1: A target consensus node resets two local sets Unconfirmed_Proposals and Confirmed_Proposals to empty sets, and reset a local variable round to 0.
    • Step 2: The target consensus node performs an RBC protocol, updates a consensus proposal that completes the RBC protocol into the set U, and adds a root hash of the consensus proposal as a truth value to represent an agreement consensus opinion.
    • Step 3: The target consensus node checks a number of consensus proposals in the set U, it is assumed that the number of proposals is x, if x<2f+1, the target consensus node continues to perform step 2; if x≥2f+1, the target consensus node traces the remaining f consensus proposals based on an erasure coding algorithm (in general, a number of consensus nodes of a blockchain needs to meet a relationship of N=3f+1), updates the consensus proposals into the set U if the consensus proposals are successfully traced, and sets root hashes of the consensus proposals to truth values; otherwise, updates the consensus proposals into the set U, and sets root hashes to null, to represent an opposition consensus opinion.
  • After that, a local Consensus Message is generated, a ConsensMessage.Unconfirmed_Proposals field of the Consensus Message is filled by using information recorded in the Unconfirmed_Proposals, a ConsensMessage.Confirmed_Proposals field is set to null, Round is set to 0, and the Consensus Message is broadcast to other consensus nodes.
  • Step 4: The target consensus node performs step 5 after receiving the Consensus Messages transmitted by the other consensus nodes in the same manner and obtaining 2f+1 Consensus Messages of the same round including the Consensus Message of the target consensus node.
  • Step 5: The target consensus node traverses consensus proposals of the set C:
    The target consensus node first determines whether the set C stores N consensus proposals and whether each consensus proposal includes 2f+1 same root hashes. If yes, this batch of iteration is ended, and the set C is used as a consensus result set of the N consensus proposals; otherwise, the following steps are performed:
    migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 same root hashes into a temporary Confirmed_Proposals set (that is, the foregoing second set, and hereinafter referred to as a set C∗ for short); migrating consensus proposals that each receive less than f+1 identical consensus votes into a temporary Unconfirmed Proposals set (that is, the foregoing third set, and hereinafter referred to as a set U∗ for short), and updating root hashes to null to represent opposition consensus opinions. If all the consensus proposals are traversed completely, step 6 is performed sequentially.
  • Step 6: Traverse consensus proposals of the set U:
    • directly placing consensus proposals with root hashes being null into the set C∗, and if a local root hash is a truth value, changing the local root hash to null;
    • migrating consensus proposals that each receive greater than or equal to 2f+1 same root hashes into the set C∗;
    • tracing consensus proposals that receive greater than or equal to f+1 and less than 2f+1 same root hashes based on an erasure coding algorithm, migrating the consensus proposals into the set C∗ if the tracing succeeds, and if a local root hash is null, changing the local root hash to a truth value; if the tracing fails, migrating the consensus proposals into the set U∗, and if a local root hash is a truth value, changing the local root hash to null; and
    • migrating consensus proposals that each receive less than f+1 same root hashes into the set U∗, and if a local root hash is a truth value, changing the local root hash to null.
  • Step 7: Merge the set C∗ back into the set C to generate a new set C, merge the set U∗ back into the set U to generate a new set U, increase Round by 1, fill an Unconfirmed_Proposals field and a Confirmed_Proposal field in the Consensus Message by using the new set C and the new set U, and broadcast the Consensus Message. Subsequently, go back to step 4.
  • The method according to the embodiments of this specification is introduced as above. It should be understood that appropriate changes may be further made without departing from the foregoing principles herein, and these changes should also be regarded as the protection scope of the embodiments of this specification.
  • Corresponding to the consensus method, an embodiment of this specification further provides a consensus node based on a Honey Badger BFT consensus mechanism. FIG. 3 is a schematic structural diagram of the consensus node 300, and the consensus node includes:
    • a consensus vote counting module 310, configured to perform a current round of consensus, to count consensus votes of N consensus proposals;
    • a first set traversing module 320, configured to traverse a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
    • a second set traversing module 330, configured to traverse a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
    • a set update module 340, configured to merge the second set into the first set, and merge the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes; and
    • a consensus result determining module 350, configured to determine a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • Based on the embodiments of this specification, a consensus node initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • Optionally, the consensus node further includes:
    an RBC protocol module, configured to transmit, based on an epoch message in an RBC protocol, consensus proposals initiated by the target consensus node to other consensus nodes, and after consensus proposals transmitted by 2f other consensus nodes through the epoch message are received, trace, based on the erasure coding algorithm, remaining consensus proposals not received, where in the first round of consensus, the target consensus node casts opposition consensus votes for consensus proposals that are untraceable based on the erasure coding algorithm in an RBC protocol stage and casts agreement consensus votes for remaining consensus proposals.
  • Optionally, the second set traversing module 330, when performed, is further configured to migrate consensus proposals that each receive only opposition consensus votes into the second set.
  • Optionally, the consensus node further includes:
    a consensus synchronization module, configured to exchange a Consensus Message respectively with other consensus nodes to count the consensus votes of the N consensus proposals, where the Consensus Message transmitted by the target consensus node includes: a field value of consensus votes of consensus proposals in the fourth set and a field value of consensus votes of consensus proposals in the first set that are locally recorded by the target consensus node.
  • Optionally, a field value of consensus votes of a consensus proposal agreed by the target consensus node in the Consensus Message is a root hash corresponding to the consensus proposal, and a field value of consensus votes of a consensus proposal opposed by the target consensus node in the Consensus Message is 0.
  • Optionally, the Consensus Message further includes: a field value used for indicating a serial number of a consensus view and/or a field value used for indicating a consensus round.
  • Optionally, after the consensus vote counting module 310 counts Consensus Messages transmitted by 2f other consensus nodes, the first set traversing module 320 starts to traverse the first set.
  • Optionally, the consensus node further includes:
    a control module, configured to: after the first set traversing module 320 traverses the first set, determine whether the first set stores the N consensus proposals and whether the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes, and if yes, end the consensus; otherwise, control the second set traversing module 330 to start to traverse the fourth set.
  • The N consensus proposals are initiated by different consensus nodes, any consensus proposal has one and only one type of consensus votes of a number greater than or equal to 2f+1, and a corresponding consensus result is a result indicated by the consensus votes of the number greater than or equal to 2f+1.
  • Apparently, the consensus node of this embodiment of this specification may be used as an entity for performing the blockchain consensus method shown in FIG. 1. Therefore, the consensus node can implement functions achieved in the blockchain consensus method in FIG. 1 and FIG. 2. Due to the same principle, the functions are not repeated herein again.
  • Corresponding to the consensus method, an embodiment of this specification further provides a blockchain system based on a Honey Badger BFT consensus mechanism. FIG. 4 is a schematic structural diagram of a blockchain system 400. The blockchain system includes a plurality of consensus nodes 410.
  • Any target consensus node 411 in the plurality of consensus nodes 410 counts consensus votes of N consensus proposals during performing a current round of consensus.
  • The target consensus node 411 traverses a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes.
  • The target consensus node 411 traverses a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus.
  • The target consensus node 411 merges the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes.
  • The target consensus node 411 determines a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • In a blockchain system of an embodiment of this specification, a consensus node initiates a plurality of rounds of iterative consensus votes on consensus proposals in a consensus stage, updates local consensus opinions according to a consensus vote result of the consensus proposals in each round of consensus, and initiates a consensus vote for the latest local consensus opinions on consensus proposals for which consensus has not been reached, so that consensus nodes in the blockchain converge in one direction for the consensus opinions of the consensus proposals, to achieve consensus faster, thereby greatly reducing rounds required for message exchange and effectively improving a consensus efficiency.
  • Apparently, the blockchain system of this embodiment of this specification may be used as an entity for performing the blockchain consensus method shown in FIG. 1. Therefore, the blockchain system can implement functions achieved in the blockchain consensus method in FIG. 1 and FIG. 2. Due to the same principle, the functions are not repeated herein again.
  • FIG. 5 is a schematic structural diagram of an electronic device, according to an embodiment of this specification. Referring to FIG. 5, in terms of the hardware, the electronic device includes a processor, and optionally includes an internal bus, a network interface, and a memory. The memory may include an internal memory, such as a high-speed random access memory (RAM), and may further include a non-volatile memory, such as at least one disk storage. Definitely, the electronic device may further include hardware required for other services.
  • The processor, the network interface, and the memory may be connected to each other through an internal bus. The internal bus may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or the like. The bus may be classified as an address bus, a data bus, a control bus, or the like. For ease of indication, only one bidirectional arrow is used for indication in FIG. 5, but it does not mean that there is only one bus or one type of bus.
  • The memory is configured to store a program. For example, the program may include program code, and the program code includes computer operation instructions. The memory may include an internal memory and a non-volatile memory, and provide an instruction and data to the processor.
  • The processor reads a corresponding computer program from the non-volatile memory to the internal memory and then runs the corresponding computer program, and forms the consensus node shown in FIG. 3 on a logical level. The processor executes the program stored in the memory and is configured to perform the following operations:
    • performing a current round of consensus, to count consensus votes of N consensus proposals;
    • traversing a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
    • traversing a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
    • merging the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes; and
    • determining a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • The foregoing blockchain consensus method disclosed in the embodiment shown in FIG. 1 of this specification may be applicable to the processor or implemented by the processor. The processor may be an integrated circuit chip, and has a signal processing capability. During implementation, the steps of the foregoing method may be completed through an integrated logic circuit of hardware or an instruction in the form of software in the processor. The foregoing processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), and the like; or may be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, a discrete gate or a transistor logic device, or a discrete hardware component. The methods, steps, and logical block diagrams disclosed in the embodiments of this specification may be implemented or performed. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor or the like. The steps of the method disclosed in combination with the embodiments of this specification may be directly embodied as being performed by a hardware decoding processor, or performed by a combination of hardware and software modules in the decoding processor. The software module may be stored in a storage medium that is mature in the art, such as a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable ROM, an electrically erasable programmable memory, or a register. The storage medium is located in the memory. The processor reads information in the memory and completes the steps of the methods in combination with hardware thereof.
  • It should be understood that the electronic device according to the embodiment of this specification can implement the functions of the consensus node shown in FIG. 3 achieved in the embodiments of FIG. 1 and FIG. 2, which is not described herein again.
  • Definitely, in addition to the software implementation, the electronic device of this specification does not exclude other implementations, such as a logic device or a combination of software and hardware. In other words, an entity for performing the following processing flow is not limited to each logic unit, and may alternatively be the hardware or logic device.
  • In addition, an embodiment of this specification further provides a computer-readable storage medium storing one or more programs. The one or more programs include instructions. The instructions, when executed by a portable electronic device including a plurality of application programs, can cause the portable electronic device to perform the method of the embodiment shown in FIG. 1 and can be configured to perform the following method:
    • performing a current round of consensus, to count consensus votes of N consensus proposals;
    • traversing a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, where the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
    • traversing a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, where the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
    • merging the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals all receive greater than or equal to 2f+1 identical consensus votes; and
    • determining a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
  • It should be understood that, the foregoing instructions, when executed by the portable electronic device that includes the plurality of application programs, can cause the consensus node shown in FIG. 3 to implement the functions of the embodiments shown in FIG. 1 to FIG. 2, which is not described herein again.
  • A person skilled in the art should understand that the embodiments of this specification may be provided as a method, a system, or a computer program product. Therefore, this specification may use a form of hardware only embodiments, software only embodiments, or embodiments with a combination of software and hardware. Moreover, this specification may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, a CD-ROM, an optical memory, and the like) that include computer-usable program code.
  • Embodiments of this specification are described above. Other embodiments fall within the scope of the appended claims. In some embodiments, the actions or steps recorded in the claims may be performed in sequences different from those in the embodiments and an expected result may still be achieved. In addition, the processes depicted in the accompanying drawings is not necessarily performed in the specific order or successively to achieve an expected result. In some implementations, multitasking and parallel processing may be feasible or beneficial.
  • The foregoing descriptions are merely embodiments of this application, and are not intended to limit this specification. For a person skilled in the art, various modifications and changes may be made to this specification. Any modification, equivalent replacement, and improvement made within the principle of this application shall fall within the scope of the claims of this specification. In addition, all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of this file.

    • Claims (11)

    1. A blockchain consensus method based on a Honey Badger Byzantine fault tolerance (BFT) consensus mechanism, comprising:
      performing, by a target consensus node, a current round of consensus, to count consensus votes of N consensus proposals;
      traversing, by the target consensus node, a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, wherein the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes of a blockchain;
      traversing, by the target consensus node, a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, wherein the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
      merging, by the target consensus node, the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals each receive greater than or equal to 2f+1 identical consensus votes; and
      determining, by the target consensus node, a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
    2. The method according to claim 1, wherein:
      before the first round of consensus is performed, the target consensus node transmits, based on an epoch message in a reliable broadcast (RBC) protocol, consensus proposals initiated by the target consensus node to other consensus nodes, and after receiving consensus proposals transmitted through epoch messages by 2f other consensus nodes, traces, based on the erasure coding algorithm, remaining consensus proposals not received, wherein in the first round of consensus, the target consensus node casts opposition consensus votes for consensus proposals that are untraceable based on the erasure coding algorithm in an RBC protocol stage and casts agreement consensus votes for remaining consensus proposals.
    3. The method according to claim 1, wherein:
      the target consensus node traverses the fourth set to further perform the following step: migrating consensus proposals that each receive only opposition consensus votes into the second set.
    4. The method according to claim 1, wherein:
      the target consensus node exchanges a Consensus Message respectively with other consensus nodes to count the consensus votes of the N consensus proposals, wherein the Consensus Message transmitted by the target consensus node comprises: a field value of consensus votes of consensus proposals in the fourth set and a field value of consensus votes of consensus proposals in the first set that are locally recorded by the target consensus node.
    5. The method according to claim 4, wherein:
      a field value of consensus votes of a consensus proposal agreed by the target consensus node in the Consensus Message is a root hash corresponding to the consensus proposal, and a field value of consensus votes of a consensus proposal opposed by the target consensus node in the Consensus Message is 0.
    6. The method according to claim 4, wherein:
      the Consensus Message further comprises: a field value used for indicating a serial number of a consensus view and/or a field value used for indicating a consensus round.
    7. The method according to claim 4, wherein:
      after Consensus Messages transmitted by 2f other consensus nodes are counted, the target consensus node starts to traverse the first set.
    8. The method according to claim 1, wherein:
      after completely traversing the first set, the target consensus node determines whether the first set stores the N consensus proposals and whether the N consensus proposals each receive greater than or equal to 2f+1 identical consensus votes, and if yes, the target consensus node ends the consensus; otherwise, the target consensus node starts to traverse the fourth set.
    9. The method according to claim 3, wherein:
      the N consensus proposals are initiated by different consensus nodes, any consensus proposal has one and only one type of consensus votes of a number greater than or equal to 2f+1, and a corresponding consensus result is a result indicated by the consensus votes of the number greater than or equal to 2f+1.
    10. A consensus node based on a Honey Badger Byzantine fault tolerance (BFT) consensus mechanism, comprising:
      a consensus vote counting module, configured to perform a current round of consensus, to count consensus votes of N consensus proposals;
      a first traversing module, configured to traverse a first set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, wherein the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
      a second traversing module, configured to traverse a fourth set, to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, wherein the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
      a set update module, configured to merge the second set into the first set, and merge the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals each comprise greater than or equal to 2f+1 identical consensus votes; and
      a consensus result determining module, configured to determine a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
    11. A blockchain system based on a Honey Badger Byzantine fault tolerance (BFT) consensus mechanism, comprising a plurality of consensus nodes, wherein:
      a target consensus node in the plurality of consensus nodes counts consensus votes of N consensus proposals during performing a current round of consensus;
      the target consensus node traverses a first set to perform the following steps: migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrating consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition consensus opinions, wherein the first set is used for storing consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes, and f is a number of fault tolerant consensus nodes;
      the target consensus node traverses a fourth set to perform the following steps: migrating consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are traceable based on an erasure coding algorithm into the second set to update to agreement consensus opinions; migrating consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes and are untraceable based on the erasure coding algorithm into the third set to update to opposition consensus opinions; and migrating consensus proposals that each receive less than f+1 identical consensus votes into the third set to update to opposition consensus opinions, wherein the first set is an absolute complement of the fourth set for the N consensus proposals, and the fourth set stores the N consensus proposals in a first round of consensus;
      the target consensus node merges the second set into the first set and merges the third set into the fourth set, to perform a next round of consensus until the first set stores the N consensus proposals and the N consensus proposals each comprise greater than or equal to 2f+1 identical consensus votes; and
      the target consensus node determines a consensus result based on counted consensus votes of the N consensus proposals in the last round of consensus.
    EP21181539.4A 2020-07-03 2021-06-24 Blockchain consensus method, node, and system based on honey badger byzantine fault tolerance consensus mechanism Active EP3933645B1 (en)

    Applications Claiming Priority (1)

    Application Number Priority Date Filing Date Title
    CN202010630013.2A CN111522800B (en) 2020-07-03 2020-07-03 Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism

    Publications (2)

    Publication Number Publication Date
    EP3933645A1 EP3933645A1 (en) 2022-01-05
    EP3933645B1 true EP3933645B1 (en) 2022-12-07

    Family

    ID=71911818

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP21181539.4A Active EP3933645B1 (en) 2020-07-03 2021-06-24 Blockchain consensus method, node, and system based on honey badger byzantine fault tolerance consensus mechanism

    Country Status (3)

    Country Link
    US (1) US11271799B2 (en)
    EP (1) EP3933645B1 (en)
    CN (2) CN112416905A (en)

    Families Citing this family (16)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    CN112907370B (en) * 2021-02-10 2022-06-03 北京航空航天大学 Multi-role driven assembly line consensus method and system
    CN112862490B (en) * 2021-04-26 2022-05-24 北京连琪科技有限公司 Output consensus method under asynchronous network
    CN113810465B (en) * 2021-08-12 2022-08-12 清华大学 Asynchronous binary consensus method and device
    CN113794576B (en) * 2021-08-12 2022-07-19 山东区块链研究院 Re-voting binary consensus method and device
    CN113783935B (en) * 2021-08-12 2022-04-01 清华大学 Byzantine fault-tolerant method and device
    CN113794694B (en) * 2021-08-25 2022-08-26 清华大学 Binary consensus method and device based on reliable broadcast
    CN113794566B (en) * 2021-08-25 2022-06-03 清华大学 Re-voting binary consensus method, device and storage medium
    CN113783708A (en) * 2021-08-25 2021-12-10 山东区块链研究院 Re-voting binary consensus method and device based on reliable broadcast
    CN113761071B (en) * 2021-10-09 2023-07-11 支付宝(杭州)信息技术有限公司 Consensus method, block chain system and consensus node
    CN113630259B (en) * 2021-10-09 2021-12-14 支付宝(杭州)信息技术有限公司 Consensus method, block chain system and consensus node
    CN114553434B (en) * 2021-10-09 2024-03-12 支付宝(杭州)信息技术有限公司 Consensus method, block chain system and consensus node
    CN113630258B (en) * 2021-10-09 2022-01-11 支付宝(杭州)信息技术有限公司 Consensus method, block chain system and consensus node
    CN114785799B (en) * 2022-04-08 2023-06-02 清华大学 Block chain consensus method, block chain replica device, computer equipment and storage medium
    CN115174090B (en) * 2022-05-20 2023-04-25 清华大学 Block chain consensus method, apparatus, computer device and readable storage medium
    CN115396432B (en) * 2022-07-29 2023-08-01 北京理工大学 Binary negotiation method and device, electronic equipment and storage medium
    CN115396504B (en) * 2022-08-23 2024-01-16 浪潮工业互联网股份有限公司 Block chain voting data caching method, equipment and medium

    Family Cites Families (22)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    WO1996027155A2 (en) 1995-02-13 1996-09-06 Electronic Publishing Resources, Inc. Systems and methods for secure transaction management and electronic rights protection
    US10812274B2 (en) 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
    WO2017066431A1 (en) 2015-10-13 2017-04-20 TransActive Grid Inc. Use of blockchain based distributed consensus control
    US20170116693A1 (en) 2015-10-27 2017-04-27 Verimatrix, Inc. Systems and Methods for Decentralizing Commerce and Rights Management for Digital Assets Using a Blockchain Rights Ledger
    CN115549923A (en) 2017-05-22 2022-12-30 维萨国际服务协会 Method and node for network for improving verification speed by tamper-proof data
    CN107231299A (en) 2017-06-07 2017-10-03 众安信息技术服务有限公司 A kind of chain route and realized the system that block chain communicates across chain
    US10984134B2 (en) 2017-07-14 2021-04-20 Microsoft Technology Licensing, Llc Blockchain system for leveraging member nodes to achieve consensus
    US10616324B1 (en) 2017-07-20 2020-04-07 Architecture Technology Corporation Decentralized ledger system and method for enterprises
    US11146380B2 (en) * 2017-08-03 2021-10-12 Parity Technologies Ltd. Methods and systems for a heterogeneous multi-chain framework
    US11018850B2 (en) 2017-12-26 2021-05-25 Akamai Technologies, Inc. Concurrent transaction processing in a high performance distributed system of record
    US20190251199A1 (en) 2018-02-14 2019-08-15 Ivan Klianev Transactions Across Blockchain Networks
    US10938557B2 (en) 2018-03-02 2021-03-02 International Business Machines Corporation Distributed ledger for generating and verifying random sequence
    US11030217B2 (en) 2018-05-01 2021-06-08 International Business Machines Corporation Blockchain implementing cross-chain transactions
    US10747201B2 (en) 2018-05-02 2020-08-18 Rockwell Automation Technologies, Inc. Subscription-based services using industrial blockchains
    CN109964242B (en) * 2018-05-25 2023-07-14 北京大学深圳研究生院 Block chain consensus method based on trust relationship
    US10949548B2 (en) 2018-10-18 2021-03-16 Verizon Patent And Licensing Inc. Systems and methods for providing multi-node resiliency for blockchain peers
    EP3566397B1 (en) 2018-12-13 2021-07-28 Advanced New Technologies Co., Ltd. Performing a change of primary node in a distributed system
    US11177962B2 (en) 2019-02-05 2021-11-16 Visa International Service Association Optimizations for verification of interactions system and method
    CN110022216B (en) * 2019-02-18 2022-02-01 西安链融科技有限公司 Efficient asynchronous Byzantine consensus method with low communication complexity and network communication platform
    US10790990B2 (en) 2019-06-26 2020-09-29 Alibaba Group Holding Limited Ring signature-based anonymous transaction
    CN114600420A (en) 2019-09-27 2022-06-07 斯凯维公司D/B/A阿索尼 Pruning entries in a tamper-resistant data storage device
    CN111342971B (en) * 2020-02-07 2023-08-08 数据通信科学技术研究所 Bayesian and preemptive consensus method and system

    Also Published As

    Publication number Publication date
    US20210314216A1 (en) 2021-10-07
    CN111522800A (en) 2020-08-11
    US11271799B2 (en) 2022-03-08
    CN112416905A (en) 2021-02-26
    CN111522800B (en) 2020-10-30
    EP3933645A1 (en) 2022-01-05

    Similar Documents

    Publication Publication Date Title
    EP3933645B1 (en) Blockchain consensus method, node, and system based on honey badger byzantine fault tolerance consensus mechanism
    US10747780B2 (en) Blockchain-based data processing method and device
    CN106406896B (en) Block chain block building method based on parallel Pipeline technology
    US6356951B1 (en) System for parsing a packet for conformity with a predetermined protocol using mask and comparison values included in a parsing instruction
    WO2020220860A1 (en) Blockchain system-based transaction processing method and apparatus
    EP4300323A1 (en) Data processing method and apparatus for blockchain network, computer device, computer readable storage medium, and computer program product
    CN105988862A (en) Distributed transaction processing method and device
    EP3934163A1 (en) Methods and consensus nodes for block generation
    CN110570311B (en) Block chain consensus method, device and equipment
    WO2020042612A1 (en) Method and device for storing and reading a message, server, and storage medium
    CN114157672B (en) S-PBFT simplified consensus protocol operation and parallel optimization method based on PBFT
    CN111159195A (en) Data storage control method and equipment in block chain system
    US11818036B2 (en) Data processing method, apparatus, and device
    WO2020029405A1 (en) Data transmission method and device
    CN110990413B (en) Block chain data storage device and rapid storage method thereof
    CN110704223B (en) Recovery system and method for single-node abnormity of database
    EP3934166B1 (en) Byzantine fault tolerance algorithm-based blockchain consensus method, apparatus, and system
    CN107104829B (en) Physical equipment matching distribution method and device based on network topology data
    CN109962861B (en) Message statistical method and device
    Jaffe et al. Distributed deadlock resolution in store-and-forward networks
    CN108718285A (en) Flow control methods, device and the server of cloud computing cluster
    WO2023123171A1 (en) Pattern complementation-based virtual network mapping method and apparatus, and computer readable storage medium
    CN113485805B (en) Distributed computing adjustment method, device and equipment based on heterogeneous acceleration platform
    EP4325811A1 (en) Data processing method and apparatus for consensus network, program product, device, and medium
    CN117009313A (en) Transaction processing method and device based on blockchain, equipment and storage medium

    Legal Events

    Date Code Title Description
    PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

    Free format text: ORIGINAL CODE: 0009012

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

    17P Request for examination filed

    Effective date: 20210624

    AK Designated contracting states

    Kind code of ref document: A1

    Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

    B565 Issuance of search results under rule 164(2) epc

    Effective date: 20211129

    RBV Designated contracting states (corrected)

    Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

    GRAP Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOSNIGR1

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: GRANT OF PATENT IS INTENDED

    INTG Intention to grant announced

    Effective date: 20220627

    GRAS Grant fee paid

    Free format text: ORIGINAL CODE: EPIDOSNIGR3

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: THE PATENT HAS BEEN GRANTED

    AK Designated contracting states

    Kind code of ref document: B1

    Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: FG4D

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: EP

    Ref country code: AT

    Ref legal event code: REF

    Ref document number: 1536739

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20221215

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R096

    Ref document number: 602021000914

    Country of ref document: DE

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: FG4D

    REG Reference to a national code

    Ref country code: LT

    Ref legal event code: MG9D

    REG Reference to a national code

    Ref country code: NL

    Ref legal event code: MP

    Effective date: 20221207

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: SE

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: NO

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20230307

    Ref country code: LT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: FI

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: ES

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: MK05

    Ref document number: 1536739

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20221207

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: RS

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: PL

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: LV

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: HR

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: GR

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20230308

    P01 Opt-out of the competence of the unified patent court (upc) registered

    Effective date: 20230524

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: NL

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: SM

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: RO

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: PT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20230410

    Ref country code: EE

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: CZ

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: AT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: DE

    Payment date: 20230626

    Year of fee payment: 3

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: SK

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    Ref country code: IS

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20230407

    Ref country code: AL

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R097

    Ref document number: 602021000914

    Country of ref document: DE

    PLBE No opposition filed within time limit

    Free format text: ORIGINAL CODE: 0009261

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: DK

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    26N No opposition filed

    Effective date: 20230908

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: SI

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: MC

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: MC

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20221207

    REG Reference to a national code

    Ref country code: BE

    Ref legal event code: MM

    Effective date: 20230630

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LU

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20230624

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: MM4A

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LU

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20230624

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: IE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20230624

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: IE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20230624