Prevent using consolidations as withdrawals

Abstract

Cancels a consolidation request if the effective balance of the target validator would exceed the max effective balance after processing it, which would result in the excess balance being withdrawn. This is an unintended way to speed up withdrawals when the consolidation queue is faster than the exit queue.

Motivation

The existing design of consolidation mechanism leaves an opportunity to use consolidation queue for exits which becomes appealing to be abused when there is an imbalance between exit and consolidation queues favoring the latter.

At the date of writing this EIP, the consolidation flaw is being heavily exploited. There are public write ups on how to speed up withdrawals by using this vulnerability.

Even though this is a UX rather than security issue, consolidation queue was never meant to be used for withdrawals, which makes the fix introduced by this EIP an important modification.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Starting from the beginning of the epoch when this EIP is activated, Consensus Layer client MUST use the modified process_consolidation_request function which code is outlined below.

New get_pending_balance_to_consolidate

def get_pending_balance_to_consolidate(state: BeaconState, target_index: ValidatorIndex) -> Gwei:
    pending_balance_to_consolidate = Gwei(0)
    for pending_consolidation in state.pending_consolidations:
        if pending_consolidation.target_index == target_index:
            source_validator = state.validators[pending_consolidation.source_index]
            pending_balance_to_consolidate += source_validator.effective_balance
    return pending_balance_to_consolidate

Modified process_consolidation_request

Note: This function is extended with the check of the target's balance after consolidation and cancels consolidation request if the balance exceeds the max effective balance.

def process_consolidation_request(
    state: BeaconState, consolidation_request: ConsolidationRequest
) -> None:
    if is_valid_switch_to_compounding_request(state, consolidation_request):
        validator_pubkeys = [v.pubkey for v in state.validators]
        request_source_pubkey = consolidation_request.source_pubkey
        source_index = ValidatorIndex(validator_pubkeys.index(request_source_pubkey))
        switch_to_compounding_validator(state, source_index)
        return

    # Verify that source != target, so a consolidation cannot be used as an exit
    if consolidation_request.source_pubkey == consolidation_request.target_pubkey:
        return
    # If the pending consolidations queue is full, consolidation requests are ignored
    if len(state.pending_consolidations) == PENDING_CONSOLIDATIONS_LIMIT:
        return
    # If there is too little available consolidation churn limit, consolidation requests are ignored
    if get_consolidation_churn_limit(state) <= MIN_ACTIVATION_BALANCE:
        return

    validator_pubkeys = [v.pubkey for v in state.validators]
    # Verify pubkeys exists
    request_source_pubkey = consolidation_request.source_pubkey
    request_target_pubkey = consolidation_request.target_pubkey
    if request_source_pubkey not in validator_pubkeys:
        return
    if request_target_pubkey not in validator_pubkeys:
        return
    source_index = ValidatorIndex(validator_pubkeys.index(request_source_pubkey))
    target_index = ValidatorIndex(validator_pubkeys.index(request_target_pubkey))
    source_validator = state.validators[source_index]
    target_validator = state.validators[target_index]

    # Verify source withdrawal credentials
    has_correct_credential = has_execution_withdrawal_credential(source_validator)
    is_correct_source_address = (
        source_validator.withdrawal_credentials[12:] == consolidation_request.source_address
    )
    if not (has_correct_credential and is_correct_source_address):
        return

    # Verify that target has compounding withdrawal credentials
    if not has_compounding_withdrawal_credential(target_validator):
        return

    # Verify the source and the target are active
    current_epoch = get_current_epoch(state)
    if not is_active_validator(source_validator, current_epoch):
        return
    if not is_active_validator(target_validator, current_epoch):
        return
    # Verify exits for source and target have not been initiated
    if source_validator.exit_epoch != FAR_FUTURE_EPOCH:
        return
    if target_validator.exit_epoch != FAR_FUTURE_EPOCH:
        return
    # Verify the source has been active long enough
    if current_epoch < source_validator.activation_epoch + SHARD_COMMITTEE_PERIOD:
        return
    # Verify the source has no pending withdrawals in the queue
    if get_pending_balance_to_withdraw(state, source_index) > 0:
        return

    # [New in EIPXXXX]
    # Verify that the consolidating balance will
    # end up as active balance, not as excess balance
    target_balance_after_consolidation = (
        get_pending_balance_to_consolidate(state, target_index)
        + source_validator.effective_balance
        + state.balances[target_index]
    )
    if target_balance_after_consolidation > get_max_effective_balance(target_validator):
        return

    # Initiate source validator exit and append pending consolidation
    source_validator.exit_epoch = compute_consolidation_epoch_and_update_churn(
        state, source_validator.effective_balance
    )
    source_validator.withdrawable_epoch = Epoch(
        source_validator.exit_epoch + MIN_VALIDATOR_WITHDRAWABILITY_DELAY
    )
    state.pending_consolidations.append(
        PendingConsolidation(source_index=source_index, target_index=target_index)
    )

Rationale

Iterating over pending consolidations

The new design introduces an iteration over pending consolidations which increases complexity of consolidation processing.

This is done to handle the case when there are multiple consolidations with the same target and each of them doesn't exceed the max effective balance while all of them together does.

Backwards Compatibility

This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.

Test Cases

• test_single_consolidation_request_at_max_eb
• test_no_pending_consolidations_exceeding_max_eb
• test_single_pending_consolidation_exceeding_max_eb
• test_multiple_pending_consolidations_at_max_eb
• test_multiple_pending_consolidations_exceeding_max_eb
• test_exceeding_max_eb_with_the_target_balance_but_not_eb
• test_exceeding_max_eb_with_the_source_eb_but_not_the_balance
• test_multiple_pending_consolidations_exceeding_max_eb_with_the_source_eb_but_not_the_balance

All of the above test cases are implemented here.

Security Considerations

When consolidation request results in max effective balance exceeded, it is cancelled on the Consensus Layer, neither request fee nor transaction gas cost are refunded in this case.

Copyright

Copyright and related rights waived via CC0.