[−][src]Module hbbft::dynamic_honey_badger
Dynamic Honey Badger
Like Honey Badger, this protocol allows a network of N nodes with at most f faulty ones,
where 3 f < N, to input "contributions" - any kind of data -, and to agree on a sequence of
batches of contributions. The protocol proceeds in linear epochs, starting at number 0, and
outputs one batch in each epoch. It never terminates: It handles a continuous stream of incoming
contributions and keeps producing new batches from them. All correct nodes will output the same
batch for each epoch. Each validator proposes one contribution per epoch, and every batch will
contain the contributions of at least N - f validators.
Epochs are divided into intervals called eras starting at 0. An era covers the lifetime of
exactly one instance of HoneyBadger. Each following era begins immediately after a batch that
-
proposes a change in the set of validators,
-
finalizes that proposed change or
-
updates the encryption schedule.
Unlike Honey Badger, this algorithm allows dynamically adding and removing validators.
As a signal to initiate converting observers to validators or vice versa, it defines a special
Change input variant, which contains either a vote Add(node_id, public_key), to add an
existing observer to the set of validators, or Remove(node_id) to remove it. Each
validator can have at most one active vote, and casting another vote revokes the previous one.
Once f + 1 validators have the same active vote, a reconfiguration process begins: They
create new cryptographic key shares for the new group of validators.
The state of that process after each epoch is communicated via the change field in Batch.
When this contains an InProgress(..) value, key generation begins and the following epoch
starts the next era. The joining validator (in the case of an Add change) must be an observer
starting in the following epoch or earlier. When change is Complete(..), the following
epoch starts the next era with the new set of validators.
New observers can only join the network after an epoch where change was not None. These
epochs' batches contain a JoinPlan, which can be sent as an invitation to the new node: The
DynamicHoneyBadger instance created from a JoinPlan will start as an observer in the
following epoch. All Target::All messages from that and later epochs must be sent to the new
node.
Observer nodes can leave the network at any time.
These mechanisms create a dynamic network where you can:
- introduce new nodes as observers,
- promote observer nodes to validators,
- demote validator nodes to observers, and
- remove observer nodes,
- change how frequently nodes use threshold encryption,
without interrupting the consensus process.
How it works
Dynamic Honey Badger runs a regular Honey Badger instance internally, which in addition to the user's contributions contains special transactions for the change votes and the key generation messages: Running votes and key generation "on-chain" greatly simplifies these processes, since it is guaranteed that every node will see the same sequence of votes and messages.
Every time Honey Badger outputs a new batch, Dynamic Honey Badger outputs the user
contributions in its own batch. The other transactions are processed: votes are counted and key
generation messages are passed into a SyncKeyGen instance.
Whenever a change receives f + 1 votes, the votes are reset and key generation for that change begins. If key generation completes successfully, the Honey Badger instance is dropped, and replaced by a new one with the new set of participants. If a different change wins a vote before that happens, key generation resets again, and is attempted for the new change.
Structs
| Batch | A batch of transactions the algorithm has output. |
| DynamicHoneyBadger | A Honey Badger instance that can handle adding and removing nodes. |
| DynamicHoneyBadgerBuilder | A Dynamic Honey Badger builder, to configure the parameters and create new instances of
|
| InternalContrib | The contribution for the internal |
| JoinPlan | The information a new node requires to join the network as an observer. It contains the state of voting and key generation after a specific epoch, so that the new node will be in sync if it joins in the next one. |
Enums
| Change | A node change action: adding or removing a node. |
| ChangeState | A change status: whether a change to the network is currently in progress or completed. |
| Error | Dynamic honey badger error variants. |
| FaultKind | Represents each way an an incoming message can be considered faulty. |
| Input | The user input for |
| KeyGenMessage | An internal message containing a vote for adding or removing a validator, or a message for key generation. It gets committed via Honey Badger and is only handled after it has been output in a batch, so that all nodes see these messages in the same order. |
| Message | A message sent to or received from another node's Honey Badger instance. |
Type Definitions
| Result | The result of |
| Step | A |