Added new virtual network implementation for tests.
Added `net::VirtualNet` as an upcoming replacement for the current networking implementation in the test, along with auxiliary functions. The new system allows easier manipulation through implemented adversaries, better reporting and should offer a more friendly API.
Documentation for the functionality can be found in `tests/README.md`.
* Make the `merkle` module private.
* Make sure the algorithm names are consistent.
* Add the Threshold Decryption and Synchronous Key Generation algorithms
to the list in the main crate documentation.
* Remove some trailing whitespace from the README.
* Remove checkboxes: all algorithms are implemented.
* Link to the algorithm implementations, not the modules.
* Use relative links in the README.
The Dynamic Honey Badger tests would currently fail _without_ faulty
nodes, because with "first" delivery, all but the first _N - f_ nodes
are lagging indefinitely.
This change makes sure we give lagging nodes a chance to finish the first
phase of the test and arrive at the batch containing the completed
`Remove` event.
* Remove unnecessary recursive method calls.
* Add `handle_message` (without the trait).
* Fix a bug where `handle_message_content` would create an `EpochState`
with the wrong number.
* Move `CoinState` and `Agreement` definitions from `agreement/mod.rs`
to `.../agreement.rs`.
* Move `DynamicHoneyBadger` definition from `dynamic_honey_badger/mod.rs`
to `.../dynamic_honey_badger.rs`.
Reorganize `dynamic_honey_badger` and `agreement` modules slightly.
* Some additional rustfmt-ing crept in due to me accidentally using a newer version.
* Move `CoinState` and `Agreement` definitions from `agreement/mod.rs`
to `.../agreement.rs`.
* Move `DynamicHoneyBadger` definition from `dynamic_honey_badger/mod.rs`
to `.../dynamic_honey_badger.rs`.
`QueueingHoneyBadger` now waits after an output, and only makes its
proposal for the next epoch when:
* there are pending transactions in the queue,
* there are pending key generation or vote messages, or
* _f + 1_ other validators have already made their proposal.
This rule should work well for small networks: With 1 - 3 nodes, it will
produce a new batch whenever at least one of them has transactions to
contribute. In larger networks, it prevents an adversary controlling _f_
nodes from producing lots of empty epochs.
An exception is made for a currently joining validator: We will commit
up to _(N + 1)² + 1_ key generation messages for them, which is the
maximum number a correct node will send.