EIP6914 discussion

[djrtwo]

General discussion thread for EIP6914 -- reuse validator indices.

Bulk of the core was merged in #3307, but there are many minor discussion points and design decisions on the table.

[djrtwo]

Note, potential non-substantive refactor #3311

[wenceslas-sanchez]

Hi guys,

I am not sure about what I am saying, don't hesitate to confirm or not. In the inactivity period, validators that don't validate attestation see their score increasing. And it decreases if they did their job. What if a validator said he wants to exit during the inactivity period (or just before); it means the validator is still active for some epoch, but don't validate; so its score increase. He exits some epochs later, during the inactivity period (or not) and its score won't change (!=0). Since the score decrease only for eligible validators, the score for an exited validator different from 0 will be kept as is until he comes back as active.

My question is, will the inactivity score be reset to 0 for the validator that is going to get the index of the validator that lived with a score != 0 when he registers ?

Thanks guys !

[dapplion]

will the inactivity score be reset to 0 for the validator that is going to get the index of the validator that lived with a score != 0 when he registers ?

Yes, the inactivity score record is reset to zero at the moment of re-assigning the validator record

consensus-specs/specs/altair/beacon-chain.md

Line 540 in f7352d1

set_or_append_list(state.inactivity_scores, index, uint64(0))

[wenceslas-sanchez]

will the inactivity score be reset to 0 for the validator that is going to get the index of the validator that lived with a score != 0 when he registers ?

Yes, the inactivity score record is reset to zero at the moment of re-assigning the validator record

consensus-specs/specs/altair/beacon-chain.md

Line 540 in f7352d1

set_or_append_list(state.inactivity_scores, index, uint64(0))

Thanks !

[ppopth]

Another complicated thing about this EIP is the equivocating_indices field in the fork-choice Store.

Currently equivocating_indices keeps the list of slashed validators and it's append-only. If those validators' indices can be reused, we should have a mechanism to remove some indices from the list. I think this is not trivial and maybe complicated.

I think, if you have an idea how to do it, it's quite a good idea to add it to the consensus-specs soon. Otherwise, this EIP seems unviable to me.

[dapplion]

@ppopth that's a great point indeed. Clearly clients should drop reused indexes from the equivocating_indices when re-assigning to a new deposit. I wonder how specific de spec should be in that regard.

For example add a more general hook, called whenever any valid imported block triggers the reuse of an index. Clients will have to do some cache clean up anyway when a reuse event happens anyway.

def on_reused_index(store: Store, index: ValidatorIndex) -> None:
    store.equivocating_indices.delete(index)

Or define a more specific mechanism, such as

def on_tick_per_epoch(store: Store, epoch: Epoch) -> None:
    head_state = store.block_states[get_head(store)]

    for index in equivocating_indices:
        if state.validators[index].withdrawable_epoch + SAFE_EPOCHS_TO_REUSE_INDEX == epoch:
            equivocating_indices.delete(index)

I would be in favor of the first approach, as I think the specific details can be iron out latter

[ppopth]

@ppopth that's a great point indeed. Clearly clients should drop reused indexes from the equivocating_indices when re-assigning to a new deposit. I wonder how specific de spec should be in that regard.

I think that will introduce a new attack vector. Let my_index be my index.

Let's say validators[my_index].withdrawable_epoch + SAFE_EPOCHS_TO_REUSE_INDEX is 100001.

Even if the withdrawable_epoch is far in the past, I can still deposit some balance and makes it effective. Let's say I deposit 32 ETH in the slot 319999. Even if my balance will be withdrawn immediately in the slot 320000, that doesn't matter because my effective balance is 32 ETH already.

Let's say at the beginning of the epoch 100001, epoch 100000 becomes justified, i.e. store.justified_checkpoint.epoch is 100000, and the state that I have effective balance will be used for the fork-choice.

Now consider the get_weight function.

def get_weight(store: Store, root: Root) -> Gwei:
    state = store.checkpoint_states[store.justified_checkpoint]
    unslashed_and_active_indices = [
        i for i in get_active_validator_indices(state, get_current_epoch(state))
        if not state.validators[i].slashed
    ]
    attestation_score = Gwei(sum(
        state.validators[i].effective_balance for i in unslashed_and_active_indices
        if (i in store.latest_messages
            and i not in store.equivocating_indices
            and get_ancestor(store, store.latest_messages[i].root, store.blocks[root].slot) == root)
    ))
    ...

Let's say I'm slashed, but not slashed in the current head block. I'm slashed like in some reorg-ed block or slashed directly from the wire. You can notice that my_index is in unslashed_and_active_indices because I'm not slashed in the head block and my_index is also in store.equivocating_indices because I'm slashed in some other way.

You can notice that my effective balance will not be counted in attestation_score, but let's say, at slot 320035, my_index is reused and I'm not in store.equivocating_indices any more. Now my effective balance will be counted in attestation_score.

[mkalinin]

Even if a validator is removed from equivocating_indices, validators[my_index].withdrawable_epoch + SAFE_EPOCHS_TO_REUSE_INDEX == epoch implies that it isn't active anymore and won't be counted by the get_weight function. Moreover, attestations from such validator won't be accepted by the network unless it is a new validator with the same index.

[ppopth]

Even if a validator is removed from equivocating_indices, validators[my_index].withdrawable_epoch + SAFE_EPOCHS_TO_REUSE_INDEX == epoch implies that it isn't active anymore and won't be counted by the get_weight function.

That's right. Thanks. I forgot the activeness.