Crate hbbft

Honey Badger BFT

An implementation of The Honey Badger of BFT Protocols, an asynchronous, Byzantine fault tolerant consensus algorithm.

Consensus

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.

Usage

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 handle_message for 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.

Algorithms

Honey Badger is modular, and composed of several algorithms that can also be used independently.

Honey Badger

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.

Dynamic Honey Badger

A modified Honey Badger where validators can dynamically add and remove others to/from the network. In addition to the transactions, they can input Add and Remove requests. The output batches contain information about validator changes.

Queueing Honey Badger

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.

Subset

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.

Broadcast

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.

Binary Agreement

Each node inputs a binary value: true or 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.

Threshold Sign

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.

Threshold Decrypt

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.

Synchronous Key Generation

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.

Serialization

hbbft supports serde: All message types implement the Serialize and Deserialize traits so they can be easily serialized or included as part of other serializable types.

Re-exports

• pub use threshold_crypto as crypto;
• pub use crate::crypto::pairing;

Modules

• binary_agreement
  Binary Agreement
• broadcast
  Broadcast
• dynamic_honey_badger
  Dynamic Honey Badger
• honey_badger
  Honey Badger
• queueing_honey_badger
  Queueing Honey Badger
• sender_queue
  Sender queue
• subset
  Subset algorithm.
• sync_key_gen
  A synchronous algorithm for dealerless distributed key generation.
• threshold_decrypt
  Collaborative Threshold Decryption
• threshold_sign
  Collaborative Threshold Signing
• transaction_queue
  An interface for a transaction queue
• util
  Utility functions

Structs

• Fault
  A structure representing the context of a faulty node. This structure describes which node is faulty (node_id) and which faulty behavior that the node exhibited (‘kind’).
• FaultLog
  A structure used to contain reports of faulty node behavior.
• NetworkInfo
  Common data shared between algorithms: the nodes’ IDs and key shares.
• SourcedMessage
  Message sent by a given source.
• Step
  Single algorithm step outcome.
• TargetedMessage
  Message with a designated target.

Enums

• Target
  The intended recipient(s) of a message.

Traits

• ConsensusProtocol
  A consensus protocol that defines a message flow.
• Contribution
  A transaction, user message, or other user data.
• Epoched
  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.
• Message
  Messages.
• NodeIdT
  A peer node’s unique identifier.
• SessionIdT
  Session identifiers.

Type Aliases

• CpStep
  An alias for the type of Step returned by D’s methods.