Real World Use Case

A single member of an IBFT Blockchain consortium wishes to leave the group, but wants to maintain their existing data.

Thus - a mechanism must exist which allows the list of validators to be overridden with a hard-coded list at a given block.

Required Changes

The overall goal of this change is that the validators for an IBFT2 network change at a given block - what this means:

• 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

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.

During construction of the ProtocolSchedule additional ProtocolSpecs will be added at the "customFork" block numbers, these