Units kept in a way optimized for easy batch extraction.

Abstract representation of a unit from the Dag point of view.

Component responsible for saving units into backup. It waits for items to appear on its receivers, and writes them to backup. It announces a successfu

The main logic of the consensus, minus all the asynchronous components.

The result of some operation within the consensus, requiring either other components should get informed about it, or messages should be sent to the n

The Dag ensuring that all units from the network get returned reconstructed in the correct order.

A structure ensuring that units added to it are output in an order in agreement with the DAG order.

The result of sending some information to the Dag.

Data type that we want to order.

A basic task scheduler scheduling tasks with an exponential slowdown A scheduler parameterized by a duration `initial_delay`. When a task is added to

An election result.

The source of finalization of the units that consensus produces. The [`FinalizationHandler::data_finalized`] method is called whenever a piece of dat

This adapter allows to map an implementation of [`FinalizationHandler`] onto implementation of [`UnitFinalizationHandler`].

The component responsible for fork alerts in AlephBFT. We refer to the documentation https://cardinal-cryptography.github.io/AlephBFT/how_alephbft_doe

A hasher, used for creating identifiers for blocks or units.

A runnable wrapper around initial unit collection.

Indicates that an implementor has been assigned some index.

Abstraction of the signing data and verifying signatures. A typical implementation of Keychain would be a collection of `N` public keys, an index `i`

Manager for tasks. Controls which tasks are performed and when.

Extends Keychain with multisigning functionalities. A single Signature can be raised to a Multisignature. Allows to verify whether a partial multisig