Validator Strategies

[naterush]

Issue

Validators need to think for themselves about when to make blocks!

Proposed Implementation

Clocks w/ different (but consistent speeds), etc. Target a DAG, etc. TODO.

[seanavery]

A potential problem with validators having different network times is that sends are calculated by self.time + some delay. This would seem to get screwy when sent to other validators who have different network times. Maybe the message sends can be based on the receivers network time to get around this.

[djrtwo]

The thing about validators having different clocks is that the Network doesn't care. That delay is based on whatever the time is in Network, not what the time is in Validator. I send a message, then once some time passes in the network, the other validator can receive it.

I could imagine more of a push on the receive (network -> validator) with the simulator doing the receives and pushing them to the validators rather than the validator having to constantly ask for new messages.

Am I understanding your comment correctly?

[seanavery]

Right, right, I get you on network "not caring" and simulator advancing the time. I think I misunderstood the original issue statement-- was just pointing out potential problem if delay was not calculated on a common "current" time reference.

The pull model makes sense to me, although I see how the push based approach would be logically simpler. I assume each priority queue level would then contain a list of msgs from_validator => to_validator => message. Then all message passes batched via the simulator from the single "network" PQ :)