An implementation of The Honey Badger of BFT Protocols, an asynchronous, Byzantine fault tolerant consensus algorithm.
A consensus algorithm is a protocol that helps a number of nodes agree on some data value. Byzantine fault tolerant systems can tolerate a number of faulty nodes f (broken, or even controlled by an attacker), as long as the total number of nodes N is greater than 3 f. Asynchronous protocols do not make assumptions about timing: Even if an adversary controls network scheduling and can delay message delivery, consensus will still be reached as long as all messages are eventually delivered.
The Honey Badger consensus algorithm is both Byzantine fault tolerant and asynchronous. It is also modular, and the subalgorithms it is composed of are exposed in this crate as well, and usable separately.
Consensus algorithms are fundamental to resilient, distributed systems such as decentralized databases and blockchains.
hbbft is meant to solve the consensus problem in a distributed application. Participating
nodes provide input to the algorithm and are guaranteed to eventually produce the same output,
after passing several messages back and forth.
The crate only implements the abstract protocols, it is the application's responsibility to
serialize, sign and send the messages. The application is required to call
every correctly signed message from a peer. Methods return a Step data
structure, which contain messages that need to be sent, fault logs indicating misbehaving
peers, and outputs.
The network must contain a number of nodes that are known to each other by some unique identifiers (IDs), which is a generic type argument to the algorithms. Where applicable, the type of the input and output is also generic.
Honey Badger is modular, and composed of several algorithms that can also be used independently.
The nodes repeatedly input contributions (any user-defined type) and output a sequence of batches. The batches have sequential numbers (epochs) and contain one contribution from at least N - f nodes. The sequence and contents of the batches will be the same in all nodes.
A modified Honey Badger where validators can dynamically add and remove others to/from the
network. In addition to the transactions, they can input
Remove requests. The
output batches contain information about validator changes.
A modified Dynamic Honey Badger that has a built-in transaction queue. The nodes input any number of transactions, and output a sequence of batches. Each batch contains a set of transactions that were input by the nodes, and usually multiple transactions from each node.
Each node inputs one item. The output is a set of at least N - f nodes' IDs, together with their items, and will be the same in every correct node.
This is the main building block of Honey Badger: In each epoch, every node proposes a number of transactions. Using the Subset protocol, they agree on at least N - f of those proposals. The batch contains the union of these sets of transactions.
One node, the proposer, inputs an item, and every node receives that item as an output. Even if the proposer is faulty it is guaranteed that either none of the correct nodes output anything, or all of them have the same output.
This is used in Subset to send each node's proposal to the other nodes.
Each node inputs a binary value:
false. As output, either all correct nodes receive
true or all correct nodes receive
false. The output is guaranteed to be a value that was
input by at least one correct node.
This is used in Subset to decide whether each node's proposal should be included in the subset or not.
Each node inputs
() to broadcast signature shares. Once f + 1 nodes have input, all nodes
receive a valid signature. The outcome cannot be known by the adversary before at least one
correct node has provided input, and can be used as a source of pseudorandomness.
Each node inputs the same ciphertext, encrypted to the public master key. Once f + 1 validators have received input, all nodes output the decrypted data.
The participating nodes collaboratively generate a key set for threshold cryptography, such that each node learns its own secret key share, as well as everyone's public key share and the public master key. No single trusted dealer is involved and no node ever learns the secret master key or another node's secret key share.
Unlike the other algorithms, this one is not asynchronous: All nodes must handle the same messages, in the same order.
hbbft supports serde: All message types implement the
Deserialize traits so they can be easily serialized or included as part of other serializable
Dynamic Honey Badger
Queueing Honey Badger
A synchronous algorithm for dealerless distributed key generation.
Collaborative Threshold Decryption
Collaborative Threshold Signing
An interface for a transaction queue
A structure representing the context of a faulty node. This structure
describes which node is faulty (
A structure used to contain reports of faulty node behavior.
Common data shared between algorithms: the nodes' IDs and key shares.
Message sent by a given source.
Single algorithm step outcome.
Message with a designated target.
The intended recipient(s) of a message.
A consensus protocol that defines a message flow.
A transaction, user message, or other user data.
An interface to objects with epoch numbers. Different algorithms may have different internal notion of epoch. This interface summarizes the properties that are essential for the message sender queue.
A peer node's unique identifier.
An alias for the type of