Module for Validator Set Managment

[UnitylChaos]

With #247 merged, Application developers can update the validator set through the EndBlock handler. Given that any system for dynamic validator sets will have some common components, it may be worth making a module for these in the SDK.

This is my basic draft for what I think would be useful Validator module:

• Store
  • CurrentValidators :: Map Pubkey Natural
  • QueuedUpdates :: Map Pubkey Natural
• Keeper
  • GetValidators :: Map Pubkey Natural
  • GetPowerOf :: Pubkey -> Natural
  • GetQueuedUpdates :: Map Pubkey Natural
  • GetQueuedUpdate :: Pubkey -> Maybe Natural
    • Maybe because update to 0 means the validator is being removed, not that there is no update
  • QueueUpdate :: Pubkey -> Natural -> ()
  • QueueUpdates :: [(Pubkey, Natural)] -> ()
• Query
  • GetValidators
  • GetPowerOf
  • GetQueuedUpdates
  • GetQueuedUpdate
• EndBlock = do
  • Update CurrentValidators with QueuedUpdates
  • Construct EndBlockResult with QueuedUpdates to send to tendermint
  • Reset QueuedUpdates for next block

This could be optionally extended to store historical changes too, by replacing QueuedUpdates with a [Map Pubkey Natural], indexed by block height, but that might be a lot of state space for chains with lots of changes, and almost certainly wouldn't be needed by all chains. (Likewise for historical validator sets)

[martyall]

this is something that I know (embarrassingly) little about so I would follow your lead on the "what is it supposed to do" part and reserve my comments for the code itself.

Is this module that you're describing responsible for updating the state needed for block proposal and tendermint consensus to work? Ive never really understood how our example applications work since we run a tendermint docker image out of the box with no modifications...

[martyall]

it might be worth proposing in this issue the concrete message and storage types though

[UnitylChaos]

This module would basically do two things:

1. Act as a queue for other modules which need to make changes to the Tendermint validator set. For example a staking module.
2. Keep a copy of the current Tendermint validator set up to date, for modules which might need that information. This is done since (AFAIK) there is no good way to query the validator set from Tendermint, so the only way for a module to know who the validators are is to follow all the updates.

To your question, yes this is basically the minimum you need to be able to make changes to how Tendermint does consensus (who is allowed to propose / who has to sign off on new blocks). The actual proposer selection is currently handled within Tenermint through a round robin scheme, but there is some discussion of making that available to applications through ABCI (tendermint/spec#193), which this module could be extended to support / expose to other modules via the keeper.

As for the concrete types, I'm not sure what you mean there.
The Natural is a power level, which doesn't have any direct meaning except that Validators representing 2/3+ of total power must sign off on each block.
And Pubkey is really just an Ed25519 pubkey, since that is currently the only validator key type Tendermint supports. Though I suppose it should be made abstract to support potential future key types such as BLS signatures.

There won't be any external transactions, so no check/deliver tx, and the only Message types that would be needed would be for wrappers around the multi arg keeper/query functions.

I'll try to code this up this weekend so we have something less abstract to look at.