...

• The genesis file must specify block at which the validators are to change, and also who the new validators are
  • It must  list the new validators, not just the expected extra data, as the new validators are required to know that at block-X they are
    responsible for producing a block (this is different to existing behaviour as the genesis file defines the block upon which all work is to be
    performed - this change defines the block to be created).
• IBFT business logic must be able to determine the currently active validators from a source other than just  the latest block - i.e. it must somehow
  factor in the "validator switch" data specified in the genesis file
• Block Validator rules must be updated to expect the validators in the block to be either as per existing voting, OR as per genesis file content
  • This will probably  be abstracted behind the VoteTallyCache
• Votes cast prior to the "change Block" will need to be discarded on a change into a custom fork

Items to Consider

Currently, the overarching behaviour of the system is defined by the ProtocolSchedule and the associated ProtocolContext. the validators and votes are (indirectly) contained within the ProtocolContext, of which
only 1 exists for the lifetime of the network.
It is proposed that ConsensusState contained with the ProtocolContext be either:

• Replaceable upon custom block
• Entire ProtocolContext be overwritten upon custom block

Approach

The existing forking process (in the ProtocolSchedule) is to be reused - however, the forks/milestones will be recognised as "customForks" in the
genesis file.

...