Make DynamicHoneyBadger parameters dynamic, too.

[afck]

Using a similar mechanism like the one to negotiate validator set changes, DynamicHoneyBadger could also allow changing parameters like the batch size (~max_future_epochs~ — that doesn't have to be the same among different nodes anyway), etc.

Also, if we don't find a good way to allow new nodes to join in any epoch (see #129), we should allow the user to restart HoneyBadger for no reason, so that new observers can join.

Implementation

We'd probably add a new Change variant BatchSize (and maybe RestartHoneyBadger). It would allow validators to vote for batch size changes in the same way they vote for adding or removing validators. Once such a change has a majority, no key generation needs to be initialized. We'd just restart HoneyBadger with the new parameter.

[pacoferre]

Just starting with this issue. I'm relatively new on Rust and also in blockchain :).

First readed "The Honey Badger of BFT Protocols" and refreshed Rust a bit. Then I added BatchSize(usize) and RestartHoneyBadger() to enum Change and fixed compile errors. Next will be tests and implementation.

Hope I'll do a good job.

[afck]

Thank you for taking on this issue! Yes, ideally batch size, threshold encryption (see #209) and subset optimization (see #243) should be dynamically configurable, and allowing a Honey Badger restart without a parameter change might also be a good idea. If you have questions, don't hesitate to ask us (here or on Gitter).

[Genysys]

Hi ,

Wondering if work was still needed on this or you had decided to go the smart contract route?

[afck]

The threshold encryption settings are already dynamic; other settings could easily be added to that. But I'd say it's not a high priority at the moment.