Submitting and finalizing a new Validator Set in POSDAO HBBFT

Since Honey Badger BFT requires a key generation before switching to the new validator set there are two phases to every epoch, and the corresponding transitions.

In the following sections we describe these interactions with the POSDAO contracts in more detail.

Definitions

Current Validator Set: Validators active in the current epoch.

Candidate Validator Set: Validators available for the next epoch.

Pending Validator Set: Validators chosen for the next epoch.

Initial Chain Spec

Needs to contain all information to start with the initial validator set, including KeyGenHistory contract state.

The hbbft_config_generator tool included in the Parity hbbft engine implementation generated a JSON data file which is read by scripts/make_hbbft.js in the posdao-contracts repository. The generated chain spec file includes the KeyGenHistory contract initialized with all Parts and Acks messages required to generate the required threshold encryption keys.

Phase 1: Regular Block Creation

The pendingValidators set returned by the ValidatorSet contract is empty in this phase, while the current validator set produces blocks according to the rules set in the chain spec.

All clients call BlockReward and Randomness contracts for every block (as system call).

TBD: Which functions specifically should be called in these contracts?

Expected side-effects:

• The calls to BlockReward and/or Randomness contracts should check if a new pending validator set should be selected.

For all clients, not only current validators, to be able to call the Randomness contract the random number has to be stored with the block (possibly in the block header).

Candidate validators poll if they have become part of the Pending Validator Set. They do so by checking the isValidator mapping of the ValidatorSet contract.

Transition 1: Start KeyGen

Triggered by: The calls to the BlockReward contract, when the conditions to initiate the transition to a new epoch has been met.

Expected side-effects:

• Pending validators are selected from the candidate validator pool
• The pendingValidators call will return the list of pending validators at this point and through phase 2

Phase 2: KeyGen

Candidate validators detect that they are chosen into the pending validator set and start submitting "Parts" and "Acks" to the KeyGenHistory contract.

Transition 2: Next Epoch Starts

Triggered by: The Parity client when the hbbft engine has enough information to generate the threshold encryption keys.

All Parity clients use system calls to call a function in the ValidatorSet contract to make the pending validators the current validators.

TBD: Which functions specifically should be called? finalizeChange() should be called

Expected side-effects:

• The current active validators need to be replaced with the pendingValidators
• The pendingValidators set must be cleared
• The KeyGenHistory contract data has to be cleared
• The epoch counters should be incremented

Reference

Setting new validators:

The blockReward contract calls newValidatorSet().

Side effects:

(emitInitiateChangeCallable() should return True)

One validator node must call emitInitiateChange() which should emit an InitiateChange event and pass a new validator set to the validator nodes!

(emitInitiateChangeCallable() should return False)

Side effects:

• validatorsToBeFinalized() should return the new set of validators and true (new epoch)
• getPools() (belongs to the staking contract) should return the pending validators

Now finalizeChange() can be called by the system at the beginning of a block (before all the block transactions).

Side effects:

• getValidators() should return the new set
• getPreviousValidators() should return the previous validator set