Unify equivocation slashing (substantive changes)

[JustinDrake]

TLDR: Unify all forms of slashing from equivocation into a single equivocation slashing condition. This is a simplification for phase 1. This PR is a simplification of #1737 focusing on substantive changes.

substantive changes

• introduce uniqueness_root in the SigningData container (with support in compute_signing_root and verify_block_signature)
• generalise ProposerSlashing and process_proposer_slashing to be handle any kind of equivocation

how it works

Signatures sign over a new uniqueness_root field which by default is set to Root() (all zero bytes). If a signed message (e.g. a signed block) has a slashing condition to protect against equivocations then the uniqueness_root is set to the hash_tree_root of the data which is meant to be unique. For example, for block proposals, a proposer must not sign two blocks with the same slot therefore signed blocks have uniqueness_root set to hash_tree_root(Slot(signed_block.slot)).

[protolambda]

It does look better than the previous PR, but I am still hesitant with introducing changes to phase0. We should discuss this more, and then schedule it with the BLS change, if we (and implementers!) can agree on this.

[JustinDrake]

We should discuss this more

Yep, should definitely discuss more :) Some dev feedback so far on technical feasibility/effort:

• @arnetheduck mentioned the change is "relatively pain-free".
• @paulhauner mentioned privately that "it's doable to add this change"
• @prestonvanloon mentioned "this change will delay a mainnet release by 2 to 4 weeks, at least"

[paulhauner]

@paulhauner mentioned privately that "it's doable to add this change"

For the sake of completeness, here's come context around that:

Paul Hauner, [21.04.20 17:28]
From a high-level perspective, I think it would nice to draw a line in the sand and say that we're not making breaking changes unless they're concrete security risks

Paul Hauner, [21.04.20 17:29]
Looking at this specific case, it's doable to add this change.

Paul Hauner, [21.04.20 17:30]
If you forced me to make a decision on this right now, I'd say to not include it. For the "line in the sand" reason and because I suspect you'll have some grumpy engineers on your hands.

Paul Hauner, [21.04.20 17:30]
Y'all have a much better idea of phase 1 and what's coming than me, so I'd leave it up to you.

---

My thoughts are still the same.

We already have a consensus-breaking change coming (v0.12 BLS) and perhaps it will save headache come phase 1. That being said, it's "one more thing to do" so it's not without cost.

[JustinDrake]

perhaps it will save headache come phase 1

Maybe there is a way to add this functionality in phase 1 in a way that the data structure changes only involve adding new fields to the end of containers. For SigningData we just add the uniqueness_root field to the end of the container. For ProposerSlashing we add validator_index, domain , etc. after the signed_header_1 and signed_header_2 fields. The signed_header_1 and signed_header_2 fields are then deprecated and must be set to their default zero value. I guess this add-fields-to-the-end-and-deprecate-unused-fields-by-setting-to-default-zero-value strategy could work for any kind of data structure upgrade in the future.

[djrtwo]

I'm pretty against this entering Phase 0 at this point. Most client efforts now are in security, stability, networking, and resource consumption optimizations. There are also a number of planned client audits starting in the next 2 to 6 weeks. Anything like this that we introduce at this point complicates all of the above efforts. My opinion is that if it isn't related to security, the state transition should remain stable.

Also, given that we have 1 additional expected equivocation type coming in Phase 1 (ShardBlock), the reduction in code paths, even if introduced then, is minimal.

[JustinDrake]

Closing as the rough consensus is pretty clear :) At a meta level it's great to see phase 0 be so mature that even relatively minor consensus changes are inappropriate.