RANDAO reveal slashing, custody period staggering and integration of custody and RANDAO reveals

[dankrad]

Currently, there is no mechanism to punish validators for revealing their Randao reveals. This could lead to a situation where these can easily bought and sold without risk for a long time in the future, which aggravates the attacks on Randao.

The logic is very similar to the early custody reveal logic.

[djrtwo]

Added some tests and have a couple of questions.

[vbuterin]

Can we think about this a lot more before we put something like this in?

I'm very worried about this approach because it means that if you propose a block, you are making yourself vulnerable to slashings if the chain forks, even if you did nothing wrong. In all other cases, the chain would need to reorg at least a week for that to happen.

I would propose this alternative: if you make an early randao reveal, you face a small penalty (eg. a week's worth of rewards), with a rule that this penalty can be applied a maximum of once every 72 days.

[vbuterin]

Also want to think more about combining the two kinds of slashing reveals as a single message type and a single verification function.

[vbuterin]

Also want to think more about combining the two kinds of slashing reveals as a single message type and a single verification function.

I have an idea in that regard: the custody key for period N is also the randao subkey for the slot at the start of period N+2. Then, we could have a rule that revealing a randao subkey early (ie. any time before the start of period N+2) would only have a small penalty, but revealing any randao subkey more than one full period early (which coincides with when the randao subkey would be used as a PoC key if it's used that way) gets you slashed. So we get both covered with one message type and one function.

[dankrad]

I have an idea in that regard: the custody key for period N is also the randao subkey for the slot at the start of period N+2. Then, we could have a rule that revealing a randao subkey early (ie. any time before the start of period N+2) would only have a small penalty, but revealing any randao subkey more than one full period early (which coincides with when the randao subkey would be used as a PoC key if it's used that way) gets you slashed. So we get both covered with one message type and one function.

Very interesting. I like this solution. So actually the custody key for the custody period starting at epoch N would then be the Randao reveal starting at epoch N+EPOCHS_PER_CUSTODY_PERIOD+2, right?

I would propose this alternative: if you make an early randao reveal, you face a small penalty (eg. a week's worth of rewards), with a rule that this penalty can be applied a maximum of once every 72 days.

What's the reason for the 72 day rule?

[dankrad]

I now unified this with the Custody reveal and removed the masking logic from the Custody Reveal scheme, since all slashing can now be performed through the RANDAO reveal logic. I had to introduce another constant to do this:

• The custody reveal is now the RANDAO reveal at period is now period * EPOCHS_PER_CUSTODY_PERIOD + CUSTODY_PERIOD_TO_RANDAO_PADDING (with Custody punishments for late reveals & deterministic staggering #872 this will have to be adapted)
• if the reveal is less than RANDAO_SLASHING_EPOCHS (=2) early, it is invalid
• If the reveal is more than CUSTODY_PERIOD_TO_RANDAO_PADDING early, then the validator gets slashed
• otherwise, a minor penalty of 1 / RANDAO_REVEAL_PENALTY_QUOTIENT (1/32) is applied

[dankrad]

Consensus of today was that we will merge this. Vitalik had some reservation about the length of CUSTODY_PERIOD_TO_RANDAO_PADDING and suggested possibly setting CUSTODY_PERIOD_TO_RANDAO_PADDING = EPOCHS_PER_CUSTODY_PERIOD. I prefer it being shorter, the code is written so that we can adjust this constant as we see fit.

[dankrad]

I merged #934 into this, so now this implements:

• Merging of RANDAO and custody reveals
• Punishing/slashing for early RANDAO reveals
• Staggering of custody periods

[vbuterin]

IMO we don't even need the verify_custody_key function here; just use the one-liner we use in phase 0:

    epoch=get_randao_epoch_for_custody_period(
            get_validators_custody_reveal_period(
                state=state,
                index=challenge.responder_index,
                epoch=slot_to_epoch(attestation.data.slot)),
            challenge.responder_index)
    assert bls_verify(responder.pubkey, hash_tree_root(epoch), challenge.responder_key, get_domain(state, DOMAIN_RANDAO, epoch))

This way we can remove the complexity of wrapping the custody key in a pointless reveal object with extraneous fields (the empty mask) and furthermore reduce the number of verify_custody_key calls to 1, which allows the function to be removed entirely (see comment above).

[dankrad]

Yes, done

[vbuterin]

Maybe for symmetry put the logic below this into a separate function process_randao_key_punitive_reveal and have the top-level function just be:

    revealed_validator = state.validator_registry[reveal.revealed_index]

    if reveal.mask == ZERO_HASH: 
        pubkeys = [revealed_validator.pubkey]
        message_hashes = [hash_tree_root(reveal.epoch)]
    else:
        masker = state.validator_registry[reveal.masker_index]
        pubkeys = [revealed_validator.pubkey, masker.pubkey]
        message_hashes = [
            hash_tree_root(reveal.epoch),
            reveal.mask,
        ]

    assert bls_verify_multiple(
        pubkeys=pubkeys,
        message_hashes=message_hashes,
        signature=reveal.reveal,
        domain=get_domain(
            state=state,
            domain_type=DOMAIN_RANDAO,
            message_epoch=reveal.epoch,
        ),
    )
    if reveal.mask == ZERO_HASH:
        process_custody_reveal(state, reveal)
    else:
        process_randao_key_punitive_reveal(state, reveal)

This, plus the suggestion below, would allow the verify_custody_key function to be cut out entirely.

[vbuterin]

Though honestly if we have this parallel structure the right approach may be to just have two objects, a CustodyKeyReveal and a EarlyReveal, where only the latter has the masking mechanism and the former does not (the former would just be a thin wrapper {validator_index: uint64, custody_key: bytes96}). This way we don't need the empty mask fields in legitimate key reveals, and the code can be separated out more instead of being an if statement that runs totally different code depending on what role the object is serving.

[dankrad]

I did this using two objects now. Pls review and check if this is your preferred method :)

[dankrad]

TBD after call:
Randao key reveal -> Early derived secret reveal
Make penalty proportional to the number of validators already punished for epoch

[dankrad]

The penalty for the early RANDAO reveal (that is not valid as a custody key anymore) is now proportional to the number of secrets already exposed. This is the simplest way of increasing punishment for a coordinated attack, and probably quite good because RANDAO reveals are useful to an attacker if they are all for the same epoch by different validators.
Possible changes:

• This is a bit unfair because the first one to get exposed gets the smallest penalty. We could extend it to also work retroactively on the ones which are already exposed, at the cost of a bit of complexity [and having to think if we want to let them exit if a validator has a secret exposed]
• Another approach would be to make it proportional to all reveals (not just from the same epoch)

[JustinDrake]

Formatting here is inconsistent

[dankrad]

Now in 1_custody-game -- looks consistent to me? What is the problem?

[CarlBeek]

Makes the formatting consistent