hbbft/src/lib.rs

159 lines
6.5 KiB
Rust
Raw Normal View History

2018-06-14 03:21:21 -07:00
//! # Honey Badger BFT
//!
2018-06-14 03:21:21 -07:00
//! An implementation of [The Honey Badger of BFT Protocols](https://eprint.iacr.org/2016/199.pdf),
//! an asynchronous, Byzantine fault tolerant consensus algorithm.
//!
//!
//! ## Consensus
//!
//! Consensus algorithms are fundamental to resilient, distributed systems such as decentralized
//! databases and blockchains. Byzantine fault tolerant systems can reach consensus with a number
2018-07-02 06:42:31 -07:00
//! of faulty nodes _f_ (including complete takeover by an attacker), as long as the total number
//! _N_ of nodes is greater than _3 f_.
//!
//! The Honey Badger consensus algorithm is both Byzantine fault tolerant and asynchronous. It does
//! not make timing assumptions about message delivery. An adversary can control network scheduling
//! and delay messages without impacting consensus, and progress can be made in adverse networking
//! conditions.
//!
//!
//! ## Crate Implementation
//!
//! This protocol does not function in a standalone context, it must be instantiated in an
//! application that handles networking.
//!
//! * The network must contain a number of nodes that are known to each other by some unique
//! identifiers (IDs) and are able to exchange authenticated (cryptographically signed) messages.
//!
//! * The user must define a type of _input_ - the _transactions_ - to the system and nodes must
//! handle system networking.
//!
//! * Messages received from other nodes must be passed into the instance, and messages produced by
//! the instance sent to corresponding nodes.
//!
//! The algorithm outputs _batches_ of transactions. The order and content of these batches is
2018-07-02 06:42:31 -07:00
//! guaranteed to be the same for all correct nodes, assuming enough nodes (_N > 3 f_) are
//! functional and correct.
//!
2018-06-14 03:21:21 -07:00
//!
//! ## Algorithms
//!
//! Honey Badger is modular, and composed of several algorithms that can also be used independently.
//!
//! [**Honey Badger**](honey_badger/index.html)
2018-06-14 03:21:21 -07:00
//!
2018-07-18 07:46:46 -07:00
//! 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
2018-06-14 03:21:21 -07:00
//! nodes.
//!
//! [**Dynamic Honey Badger**](dynamic_honey_badger/index.html)
//!
//! 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.
//!
2018-07-18 07:46:46 -07:00
//! [**Queueing Honey Badger**](queueing_honey_badger/index.html)
//!
//! 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.
//!
2018-08-14 06:06:51 -07:00
//! [**Subset**](subset/index.html)
2018-06-14 03:21:21 -07:00
//!
2018-07-02 06:42:31 -07:00
//! 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.
2018-06-14 03:21:21 -07:00
//!
//! This is the main building block of Honey Badger: In each epoch, every node proposes a number of
2018-08-14 06:06:51 -07:00
//! transactions. Using the Subset protocol, they agree on at least _N - f_ of those
2018-06-14 03:21:21 -07:00
//! proposals. The batch contains the union of these sets of transactions.
//!
//! [**Broadcast**](broadcast/index.html)
2018-06-14 03:21:21 -07:00
//!
//! 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.
2018-06-14 03:21:21 -07:00
//!
2018-08-14 06:06:51 -07:00
//! This is used in Subset to send each node's proposal to the other nodes.
2018-06-14 03:21:21 -07:00
//!
2018-08-30 01:22:56 -07:00
//! [**Binary Agreement**](binary_agreement/index.html)
2018-06-14 03:21:21 -07:00
//!
//! 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.
2018-06-14 03:21:21 -07:00
//!
//! This is used in Subset to decide whether each node's proposal should be included in the subset
//! or not.
2018-06-14 03:21:21 -07:00
//!
2018-08-14 05:56:32 -07:00
//! [**Coin**](coin/index.html)
2018-06-14 03:21:21 -07:00
//!
2018-07-02 06:42:31 -07:00
//! Each node inputs `()` to initiate a coin flip. Once _f + 1_ nodes have input, either all nodes
2018-06-14 03:21:21 -07:00
//! receive `true` or all nodes receive `false`. The outcome cannot be known by the adversary
//! before at least one correct node has provided input, and is uniformly distributed and
2018-06-14 03:21:21 -07:00
//! pseudorandom.
//!
//! [**Threshold Decryption**](threshold_decryption/index.html)
//!
//! 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**](sync_key_gen/index.html)
//!
//! 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.
//!
2018-06-14 03:21:21 -07:00
//! ## Serialization
//!
//! `hbbft` supports [serde](https://serde.rs/): All message types implement the `Serialize` and
2018-06-14 03:21:21 -07:00
//! `Deserialize` traits so they can be easily serialized or included as part of other serializable
//! types.
// TODO: Remove this once https://github.com/rust-lang-nursery/error-chain/issues/245 is resolved.
#![allow(renamed_and_removed_lints)]
2018-07-31 13:27:22 -07:00
// We put algorithm structs in `src/algorithm/algorithm.rs`.
#![cfg_attr(feature = "cargo-clippy", allow(module_inception))]
extern crate bincode;
2018-05-29 08:50:48 -07:00
extern crate byteorder;
#[macro_use]
extern crate failure;
2018-05-29 12:59:21 -07:00
extern crate init_with;
2018-05-20 04:51:33 -07:00
#[macro_use]
extern crate log;
2018-05-24 09:58:10 -07:00
extern crate pairing;
extern crate rand;
#[macro_use]
extern crate rand_derive;
extern crate reed_solomon_erasure;
extern crate serde;
#[macro_use]
extern crate serde_derive;
2018-08-01 09:56:36 -07:00
pub extern crate threshold_crypto as crypto;
2018-08-09 02:51:31 -07:00
extern crate tiny_keccak;
2018-08-30 01:22:56 -07:00
pub mod binary_agreement;
2018-04-30 08:55:51 -07:00
pub mod broadcast;
2018-08-14 05:56:32 -07:00
pub mod coin;
2018-06-14 08:41:35 -07:00
pub mod dynamic_honey_badger;
pub mod fault_log;
mod fmt;
pub mod honey_badger;
2018-10-10 07:11:27 -07:00
mod messaging;
mod network_info;
pub mod queueing_honey_badger;
2018-08-14 06:06:51 -07:00
pub mod subset;
pub mod sync_key_gen;
pub mod threshold_decryption;
2018-10-10 07:11:27 -07:00
mod traits;
pub mod transaction_queue;
Better proptest persistence through deterministic randomness. (#248) * Add support for RNG instantiation in proptests. * Use `proptest` module strategy to create the rng for `net_dynamic_honey_badger`. * Use seed generation instead of RNG instantiation in tests. * Remove fixed RNG in `generate_map`. * `VirtualNet` now supports setting the random generator through the builder. * Add missing `time_limit` field to `::std::fmt::Debug` trait implementation on `NetBuilder`. * Pass an instantiated random number generator through `NewNodeInfo` as a convenience. * Make the random number generator of `DynamicHoneyBadgerBuilder` configurable, at the cost of now requiring mutability to call `build_first_node()`. * Ensure RNGs are derive from passed in seed in `net_dynamic_hb` tests. * Correct inappropriate use of `random::Random` instead of `Rng::gen` to generate dependent values in `binary_agreement`. The original implementation used `rand::random()`, which will always use the `thread_rng`, ignoring the fact that an RNG has actually been passed in. * Do not use `OsRng` but passed in RNG instead. * Use reference/non-reference passing of rngs more in line with the `rand` crates conventions. * Document `rng` field on `DynamicHoneyBadger`. * Make `SyncKeyGen` work with the extend (`encrypt_with_rng`) API of `threshold_crypto`. * Use passed-in random number generator in `HoneyBadger`. * Create `SubRng` crate in new `util` module to replace `create_rng()`. * Use an RNG seeded from the configure RNG when reinitializing `DynamicHoneyBadger`. * Use the correct branch of `threshold_crypto` with support for passing RNGs.
2018-10-02 07:24:51 -07:00
pub mod util;
2018-10-10 07:11:27 -07:00
pub use messaging::{SourcedMessage, Target, TargetedMessage};
pub use network_info::NetworkInfo;
pub use traits::{Contribution, DistAlgorithm, Message, NodeIdT, Step};