Create ValidatorSet class

[djrtwo]

Issue

We should consider moving the validator set initialization and variables out of settings.py and have it be its own class ValidatorSet.

Will be useful to have it as its own logical unit for when (if) we start simulating changes to the validator set. Will also be useful to be able to test different configurations of validators more easily (number of validators, distribution of weights, etc).

Proposed implementation

• Create class ValidatorSet
• Move variables related to the validator set (ex: NUM_VALIDATORS, VALIDATOR_NAMES, etc) to ValidatorSet. These can be configured on __init__.
• ValidatorSet can have list (set?) of Validators.
• Move specific validator weights and names to each Validator.
• Refactor references to validators and settings vars to reference the validator_set on network.
• Adversary can attack by manipulating a copy of the current network ValidatorSet. I think this will allow us to remove or at least simplify ModelValidator and related models

[djrtwo]

@naterush Let me know your thoughts on this.

[naterush]

Some refactoring here seems like a great call - testing w/ settings.py as it exists now is pretty messy, and this seems like it would be amazing once we have validator set changes :)

Quick (possibly stupid) question - would this require safety oracles (and therefore validators) to be aware of the ValidatorSet that they are apart of? Meaning, because safety oracles need to know things about the validators that exist and their weights, would we have to pass a reference to the ValidatorSet to the validators/oracles themselves?

Other than that (which might be a non-issue, or just a bit complicated) this seems like a great change to me. Let me know what you think @djrtwo.

[djrtwo]

Well the safety oracle already does know about the validator set by referencing the VALIDATOR_NAMES and WEIGHTS.

But to answer your question in general -- yes, validators must be aware of the current validator set in a real life version of this consensus protocol, otherwise they could not make any rational decisions about anything really.

The validator_set being known by the public at any given time is key to a number of aspects of bonded validator PoS systems.

[djrtwo]

I think we should get testing merged in before a medium refactor like this, right?

[naterush]

Sure, more so meant as an implementation detail - if this is going to require passing a reference to the current ValidatorSet to be passed to each validator and safety oracle. This seems fine to do, though.

Yep, this seems like a good refactor once we get testing merged in. It relies on the oracle PRs (or at least one of them), as well. I should be able to clean up the testing branch and soon :)

[djrtwo]

Safety oracle will need to have validator_set passed in. Validators should know which ValidatorSet they are a part of. I think that bidirectional link (validator_set having validators and validators knowing their validator_set) makes sense and mimics the requirements of a real network.

A validator is the one that would be using a safety oracle, right? And when they use that safety oracle, they would pass in the full validator_set.

[naterush]

Have been thinking about this a bit - and there’s one more change that I think would be useful.

The current way validator set changes are specified for CBC Casper is on a “by-block” level - so (ignoring efficiency for a second), each block defines the validator set that must finalize the next block. A natural way of implementing this might be having each block define a next_block_validator_set. This makes passing the validator_set into the safety oracle (as it is called on a specific block) more reasonable given this "by-block" switching.

Also, the network would have a single master_validator_set, which is the union of all next_block_validator_sets for all blocks.

[djrtwo]

@naterush Starting this today. I'll get a work in progress ([WIP]) PR up as soon as possible for initial review.