IF: Support transition from legacy consensus to HotStuff consensus

[arhag]

Depends on #1511, #1532, #1610, #1631, and AntelopeIO/reference-contracts#26.

Block header extension to capture new finalizer set.

Producer plugin config allows for specifying block finalization key pairs.

Questions:

• When do new messages get sent over P2P network?
  • KH: I suggest 5.0 always send these messages. But if we are concerned about a network not ever activating hotstuff, maybe add an option to disable them?

For this issue, we are not switching existing tests over to use IF.

However, a new unit test is needed that switches to IF to test the transition.

To implement that new test, we will need to pull in AntelopeIO/reference-contracts#26 bios contract to set the first finalizer set and transition to HotStuff.

Also add constraints to set_finalizers host function to meet needs of #1569: ✓

• Each finalizer can have a description that does not exceed 256 bytes. ✓
• There can be a maximum of 2^16 finalizers in the finalizer set. ✓

After HotStuff transition, the parameters in block_header_state used by the old consensus algorithm (LIB, proposed LIB, etc.) are no longer needed and should not be used. But the fork choice rule in fork DB uses the LIB from block_header_state to decide on the best chain. Additionally, plugins currently expect block_header_state to be immutable.

We would like to keep the simple concept that the block_header_state is immutable and computed purely from the prior block_header_state and the new block_header. This means block_header_state cannot store LIB and the active finalizer set.

So we need to still store the real LIB in fork DB (fork choice rule must use this LIB once transitioned to HotStuff rather than the obsolete one in block_header_state).

Open questions:

• Where do we store the active finalizer set since we cannot store it in block_header_state? [Maybe store in qc_chain?]
• Do we need to store the active finalizer set in the portable snapshot? If so, how does this impact the determinism of the portable snapshot?
• What else do we need to store in the portable snapshot to allow for nodes to safely recover liveness?
• Do we need to include the active finalizer set as part of the integrity hash? If so, how does this impact the determinism of the integrity hash?

[heifner]

Seems like this depends on fcecin@74295f2 which is not currently in hotstuff_integration

[heifner]

Block header extension

• host function sets finalizer set in pending block
• multiple calls in one block overwrite value in pending block
• proposed finalizer set added to block header extension

Active schedule

• Follow pattern of existing producer schedule and store in block_header_state
• Update snapshot with snapshot_block_header_state_v2 work under IF: Add new snapshot version to hold consensus Savanna state #1558
• When block becomes LIB proposed finalizer set becomes active finalier_set

[heifner]

• Any desire to update keosd to support BLS keys? Any desire to allow nodeos to use keosd to retrieve finalizer BLS private keys?