Aleph Consensus

Overview

Aleph is an asynchronous and Byzantine fault tolerant consensus protocol aimed at ordering arbitrary messages (transactions). It has been designed to operate continuously under conditions where there is no bound on message-delivery delay and under the assumption that there is a significant probability of malicious behavior, making it an excellent fit for blockchain-related applications. For more information, check the paper

This repository contains a Rust implementation of AlephBFT that offers a convenient API enabling seamless application to various problems. The prime application of the repository is the consensus engine (sometimes called the "finality gadget") of the Aleph Zero blockchain.

Detailed documentation

If the crate's documentation seems to be not comprehensive enough, please refer to the detailed version.

Implementation status

• current version is asynchronous, so it's driven by consensus events as opposed to some clock ticks
• while being asynchronous, the performance is still optimal in partially synchronous environment
• guaranteed safety even in asynchronous environment
• BFT - secure if less than one third of the committee is malicious
• secure against fork bombs, for details see the paper
• network overhead optimized to not send all parents hashes but a bitmap and a control hash
• thorough testing, including malicious scenarios, and high code coverage

Future work

• Asynchronous liveness is an important theoretical property and there is a lot of technical sophistication that comes in the design of AlephBFT in order to achieve it, however on the practical side there is still little evidence that performing such attacks against liveness in real-world scenarios is possible. Still, no matter how unlikely such attacks might be, we take them very seriously and plan to add randomness to AlephBFT in one of the future releases. We decided to go for a version without randomness first, as it gives an incredibly simple and at the same time secure and robust BFT consensus protocol. Adding randomness introduces some complexity into the protocol, so it makes sense to add it on top of a well-tested, working product. The API of the protocol will not change and we will make the use of randomness configurable.
• We see a big value in keeping a critical piece of code such as a consensus protocol as self-contained as possible, so we would like to get rid of the only major dependency - parity-scale-codec

Using the crate

• Import AlephBFT in your crate toml [dependencies] aleph-bft = "0.3.1"
• AlephBFT requires user to provide it with an implementation of the following traits:
  • The [DataIO][dataio-link] trait is an abstraction for a component that provides data items, checks availability of data items and allows to input ordered data items. DataIO is parametrized with a Data generic type representing the type of items we would like to order. rust pub trait DataIO<Data> { type Error: Debug + 'static; fn get_data(&self) -> Data; fn check_availability( &self, data: &Data, ) -> Option<Pin<Box<dyn Future<Output = Result<(), Self::Error>> + Send>>>; fn send_ordered_batch(&mut self, data: OrderedBatch<Data>) -> Result<(), Self::Error>; }
  • The [KeyBox][keybox-link] trait is an abstraction for digitally signing arbitrary data and verifying signatures created by other nodes. rust pub trait KeyBox: Index + Clone + Send { type Signature: Signature; fn sign(&self, msg: &[u8]) -> Self::Signature; fn verify(&self, msg: &[u8], sgn: &Self::Signature, index: NodeIndex) -> bool; }
  • The [Network][network-link] trait defines the functionality we expect from the network layer: rust pub trait Network<H: Hasher, D: Data, S: Encode + Decode>: Send { type Error: Debug; fn send(&self, data: NetworkData<H, D, S>, node: NodeIndex) -> Result<(), Self::Error>; fn broadcast(&self, data: NetworkData<H, D, S>) -> Result<(), Self::Error>; async fn next_event(&mut self) -> Option<NetworkData<H, D, S>>; }
• Having all the above traits implemented, one can create a [Committee Member][member-link] and run it as an asynchronous task with an execution engine of choice.

Dependencies

The repository is mainly self-contained. It is implemented using Rust's async features and depends only on the futures create from the standard library. Moreover, it has some usual dependencies like log and rand and one bigger for encoding, namely parity-scale-codec. In future work, we plan to get rid of this dependency.

Examples

There is a basic implementation of an honest committee member that is not cryptographically secure and serves only as a working example of what has to be implemented and not how it should be implemented. The example may be run using:

cargo run --example dummy_honest my_id n_members n_finalized

my_id -- our index, 0-based
n_members -- size of the committee
n_finalized -- number of data to be finalized

Tests

There are many unit tests and several integration tests that may be run by standard command cargo test --lib or cargo test --lib --skip medium if you want to run just small tests. Alternatively, you may run the run_local_pipeline.sh script.

Code Coverage

You may generate the code coverage summary using the gen_cov_data.sh script and then a detailed raport for every file with cov_report.sh. Make sure to first install all the required tools with install_cov_tools.sh.

Resources

• Papers: current version, old version
• docs: crate documentation, reference

License

AlephBFT is licensed under the terms of the the Apache License 2.0.

Founding

The implementation in this repository is founded by Aleph Zero Foundation.