Create ValidatorSet class about cbc-casper HOT 8 CLOSED

@naterush Let me know your thoughts on this.

from cbc-casper.

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.

from cbc-casper.

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.

from cbc-casper.

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

from cbc-casper.

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 :)

from cbc-casper.

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.

from cbc-casper.

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.

from cbc-casper.

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

from cbc-casper.