Set validator weights to zero if they equivocate/make invalid block?

[vladzamfir]

Issue

• What's wrong?
• How are things currently?
• How should things be?

Proposed Implementation

• Weights defined in views
• Modify the fork choice rule
• Include invalid bets/equivocation in the justification

[naterush]

Some test situations to make sure the validator does not freak out if it receives an equivocation or invalid block:

1. Invalid Block

• Does not contain the correct fields.
• The estimate is not justified (with weight from the senders view)
• New_messages's justification lies about what has been seen (e.g. justification must be at least as recent as the previous justification from validator).
• Justification contains two messages from one validator, as if there as an equivocation, but these messages are not an equivocation!
• Two messages justifications contain messages that should be equivocations, but the sender of these two messages didn't notice they were.
• Make a decision on a block that is not in forkchoice.

2. An equivocation:

• Two blocks from the same sender with the same sequence number
• Two blocks from the same sender where there is not a clear order between the two protocol states attested to by the justifications.

Note that some of these require the entire justification of the message to be seen before this can be detected. Thus, it likely makes sense there are some "initial quality checks:" message is a block and contains the correct fields (maybe a bit of PoW ;) ). Then, when the justification for the message arrives, the second round of quality checks occur.

This likely should occur in the node, and then it is passed to the validator's view as either a) an equivocation, b) an invalid block, or c) a good block to add! The response in these three cases should be different (e.g. updating forkchoice weights to 0 if a, b), and the view needs additional structure to support these types of messages.

[naterush]

(Not Complete) List of Necessarily Changes:

1. Forkchoice needs weight to be defined locally, rather than from the validator themselves. This is both for the case that you see a validator equivocate, but also when a validator wants to check that another validators forkchoice is justified (with whatever weights they should have at this point).
2. Justifications need to be a dict that maps validator => set(messages), so validators can show other validators equivocations they want. We might also want to add more information to these justifications (such as if message is valid, etc).